quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] Quilt translation update


From: Jean Delvare
Subject: Re: [Quilt-dev] Quilt translation update
Date: Fri, 9 Feb 2024 22:02:23 +0100

Hi Andreas,

On Fri, 9 Feb 2024 16:27:45 +0100, Andreas Grünbacher wrote:
> Am Fr., 9. Feb. 2024 um 15:51 Uhr schrieb Andreas Grünbacher <agruen@gnu.org>:
> > Am Fr., 26. Jan. 2024 um 11:09 Uhr schrieb Jean Delvare <jdelvare@suse.de>: 
> >  
> > > OK, I do find it clean, but I wrote it in the first place, so that
> > > doesn't count. Therefore, I discussed this with my colleagues to get a
> > > neutral opinion. The generally understood the meaning, but agreed it
> > > could be improved.
> > >
> > > The first suggestion was to replace "this must happen first" with "they
> > > must come first", to make it clean that what matters is the order of
> > > the commands in the %prep section.
> > >
> > > The second suggestion was to add an example. It could look like this:
> > >
> > > "For example, a %prep section where you first unpack a tarball, then
> > > apply patches, and lastly perform a tree-wide string substitution, is
> > > not OK. For "quilt setup" to work, it would have to be changed to
> > > unpacking the tarball, then performing a tree-wide string substitution,
> > > and lastly applying the patches."
> > >
> > > Would either or both work for you?  
> >
> > the problem I have with all this is that it makes recommendations that
> > are incorrect, and lead to bad package maintenance practices. It

I didn't make up the example, it's actually something a package
maintainer was doing, and that person came to me asking why that
didn't work, therefore prompting for better documentation of what is
supported and what isn't. That's what I'm trying to do here.

The bug is public so you can read the details if you are interested:
  https://bugzilla.opensuse.org/show_bug.cgi?id=1203791

Personally, I wish people weren't doing that, and %prep sections in
spec files were always just a tar -x followed by applying patches and
that's it. However, rpmbuild supports arbitrary commands in %prep, and
people tend to use all the liberty they are given.

> > simply isn't true that the last thing the %prep section should do is
> > apply the patches; actually, it should unpack the tarball and apply
> > the patches *first*, and then it can do other things.
> >
> > Quilt setup works by executing the %prep section and watching what it
> > does, and by then unpacking the tarball and storing which patches were
> > applied in the series file. Any tree-wide renaming in the %prep
> > section before applying the patches is asking for trouble.  

As you probably have found meanwhile, what you described is how "quilt
setup" used to work. The so-called "fast mode" which I implemented 9
years ago, and made the default mode 2 years ago, is implemented
differently.

> Well, that actually depends on which setup mode is used (--slow or
> --fast). But we really shouldn't rely on any side effects of how
> --fast is implemented.

Actually we shouldn't rely on any side effects of how *--slow* is
implemented. Given that --fast is the default for 2 years now, I feel
comfortable documenting how this mode works, and not document the
slightly different behavior of the slow mode which nobody should be
using anymore.

I'd rather drop the --slow option entirely than make the documentation
more complex by trying to explain the different behavior of the slow
mode for unusual %prep section contents. Getting rid of --slow was more
or less the plan since the beginning anyway, as this would allow for
nice code cleanups.

-- 
Jean Delvare
SUSE L3 Support



reply via email to

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