bug-patch
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-patch] Regression in symbolic link handling


From: Jean Delvare
Subject: Re: [bug-patch] Regression in symbolic link handling
Date: Wed, 18 Feb 2015 12:49:57 +0100

Hi Tim,

On Wed, 18 Feb 2015 11:34:38 +0000, Tim Waugh wrote:
> On Wed, 2015-02-18 at 11:58 +0100, Jean Delvare wrote:
> > A number of patches in openSUSE packages fail to apply with GNU patch
> > 2.7.4 while they did apply fine with versions 2.7.3 and earlier. The
> > problem is when one of the path components of a file is a symbolic link
> > to a directory.
> 
> Why do the patches touch those files via their symlinked pathnames
> rather than using direct pathnames? For git-generated patches, for
> example, only the direct pathnames are used.

I asked myself exactly the same question. In fact it happens when a
package is built from several sources. In this case it is package rpm,
which is built from rpm but also beecrypt and db. The beecrypt and db
archives are extracted inside the rpm source tree. It looks like:

rpm-4.12.0.1
rpm-4.12.0.1/beecrypt-4.1.2
rpm-4.12.0.1/db-4.8.30

When we have local patches which touch these components, it is quite
inconvenient to have to include the version number in all paths, as it
breaks as soon as the components are upgraded. So what we do is that we
create symbolic links like this:

rpm-4.12.0.1
rpm-4.12.0.1/beecrypt-4.1.2
rpm-4.12.0.1/beecrypt -> beecrypt-4.1.2
rpm-4.12.0.1/db-4.8.30
rpm-4.12.0.1/db -> db-4.8.30

And all patches refer to the links so that the version doesn't show in
the patch file.

If we can no longer patch files through symbolic links, that means we
have to include the version number in all paths in such patches, and
update the patch whenever the version number changes. That would be a
maintenance pain as you can imagine, which is why we would like to
avoid it.

Thanks,
-- 
Jean Delvare
SUSE L3 Support



reply via email to

[Prev in Thread] Current Thread [Next in Thread]