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

Re: Adding lzma to dpkg's Pre-Depends

Steve Langasek writes ("Re: Adding lzma to dpkg's Pre-Depends"):
> On Tue, Jul 29, 2008 at 09:28:01PM +0200, Andreas Barth wrote:
> > What advantage would we (as in Debian) have if dpkg pre-depends on lzma,
> > instead of the packages pre-depending on lzma?
> If dpkg internalizes the lzma support (by static linking, dynamic linking,
> or depending on the lzma binary), and packages which use lzma pre-depend on
> the correct version of dpkg, then the pre-dependency on dpkg is transitional
> and can go away after a release cycle.

No, unless the dpkg.deb binary package were to actually _contain_ the
lzma code, dpkg would have to Pre-Depend on it forever (or it would
have to be made Essential).  Dynamic linking or expecting to use the
lzma binary from another package would not suffice.

> What is fundamentally different about lzma that it should be handled
> differently than gzip and bzip2?

lzma is much more of a minority interest than gzip.  We do not expect
ever to transition the entire archive to use gzip.  The approach taken
with bzip2 was a mistake and should not be repeated.

> > If there isn't an real and strong advantage, I'd rather think it's
> > better to not do it.  And, BTW, if dpkg pre-depends on lzma, lzma is
> > basically essential.
> It's essential for the purposes of calculating the Essential: yes closure,
> and not essential in the sense that packages which use its functionality
> independently still need to depend on it directly.

Making a package Essential in that sense is very expensive and should
not be done without a good reason.

The last time we had this conversation it appeared that the only
reason why Pre-Depends in each package wasn't favoured was because our
package building tools were not capable of including that dependency
in a sufficiently automated way.  I think that is a really poor


Reply to: