Re: [Quilt-dev] Quilt translation update

[Andreas Grünbacher]

Jean,

Am Fr., 9. Feb. 2024 um 22:02 Uhr schrieb Jean Delvare <jdelvare@suse.de>:
> 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.

I'm all for better documentation. But the setup command is severely
broken right now. Executing the %prep section in the current working
directory is just insane. So instead of documenting that madness, we
should really fix this.

Let's start with tar. The "slow" setup runs %prep in a temporary
directory which it throws away at the end, and then it expands the
tarball(s) a second time. That was relatively easy to implement
initially, but it's annoying with large tarballs.

How about improving the tar wrapper so that it saves away the expanded
tarball, but without running %prep in the current working directory?
I'm attaching a proof-of-concept script that creates a hardlinked copy
of the expanded tarball. (It's mostly tar command line parsing, which
isn't that easy.)

Try out as follows:

  # put the attached tar-wrapper script into the current directory
  $ ln -s tar-wrapper tar
  $ export QUILT_WORKDIR=.
  $ ./tar -xaf linux-6.7.4.tar.xz    # this creates linux-6.7.4/
  $ ./tar -xaf linux-6.7.4.tar.xz    # when run again, this complains
  Refusing to overwrite linux-6.7.4

Beware that the script may contain bugs and might run "rm -rf" in the
wrong directory by accident!

Andreas

tar-wrapper
Description: Binary data