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

Re: Standardizing the layout of git packaging repositories



Reinhard Tartler <siretart@gmail.com> writes:

> Other than that, I am really curious to learn more about the
> fundamental design problems with pristine-tar.
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=pristine-tar doesn't
> look great, but not too bad either.

The fundamental concern with pristine-tar is that it has to adapt to any
further changes in how any of the underlying tools output their data.  In
other words, if gzip or xz gain some new optimization or find a new way of
compressing something that's compatible with the existing protocol,
pristine-tar may discover that it cannot recreate the original file using
the current version of the tools.

Joey took various approaches to work around this, including shipping some
of the older versions of the compressors in the package.  However, the
issue also applies to tar, and so far has been addressed by modifying tar
to add a backword-compatibility mode.  This probably isn't the best
long-term solution; instead, pristine-tar probably needs to include its
own copy of various older tar versions so that it can recreate older files
without depending on such support in newer versions of the tools.

There are more details about this issue in the wnpp orphaning bug.

I think calling them fundamental design problems is a bit strong, but I
also consider pristine-tar to be a useful optimization, not critical data
storage.  In other words, if pristine-tar fails to reconstruct the
tarball, I can just grab it from the archive and go on about my work until
I or someone else has a chance to fix it, so I don't consider this failure
to be as serious as an actual data loss.  (This so far has only happened
to me once, to note, when tar changed its representation for certain types
of file names, which was later fixed with a compatibility patch in tar.)
If you are absolutely relying on pristine-tar as the only source for a
file, you may be more concerned about the possible incompatibilities with
future tool revisions.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: