[ CCed Mohammed for the lzma package size reduction part. ]
Hi,
On Fri, 25 Jan 2008, Ian Jackson wrote:
> Raphael Hertzog writes ("Bug#456332: dpkg could use an elevated pre-depends
> or depends on lzma"):
> > The debian/control field is the only viable option IMO. It would be
> > somewhat similar to the Package-Type: header which has no real use except
> > influencing the behaviour of another tool during the build.
>
> Having slept on it I think this is the right answer.
> Compression-Type: gzip|bzip2|lzma|...
> converted into
> Pre-Depends: deb-decompressor-lzma
> by dpkg-gencontrol
The problem with that is when unpacking and repacking a .deb with a
different compression, dpkg-deb would have to munge the Pre-Depends.
Even if that should be safe with such virtual package, I don't feel
comfortable doing that.
The other problem is that all current packages using bzip2 or lzma
would have to gain such dependency (supposedly gzip ones as well?!),
there should not be many using bzip2 or lzma, though.
On Fri, 2008-01-25 at 18:54:10 +0000, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: Bug#456332: dpkg could use an elevated
> pre-depends or depends on lzma"):
> > I'm still not convinced that this is the right approach, Pre-Depends are
> > supposed to not be used lightly. Does the package need to be configured,
> > isn't a simple dependency enough ?
Yes, I'm not convinced either that using a dependency is the way to go
(although yes, I agree that if we'd have to use one, that should be a
Pre-Depends).
> > And we're speaking of:
> > $ dpkg -s lzma | grep Installed
> > Installed-Size: 292
> > $ dpkg -s bzip2 | grep Installed
> > Installed-Size: 124
>
> Between them that's nearly half a megabyte. (That's not to mention
> the couple more we're bound to acquire if we make this actually work
> well.)
Probably lzma_alone (104 KiB) could be removed at some point from the
lzma package, and few docs moved to lzma-dev where they belong (20 KiB).
Also probably only that one package in base switched to lzma we'd recover
that space anyway.
> The downsides of a Pre-Depends is that it makes installation ordering
> much more tricky - but this Pre-Depends is in fact an accurate
> reflection of the situation. If the Pre-Depends is absent and
> installation operations are done that it would have prevented, those
> operations will fail.
Ian, I can see your point, about the correctness (depends on demand),
and not encoding the archive state in the metadata of all .deb (virtual
package). But on the other hand it's dpkg who is calling the lzma
binary, it's an implementation detail as Chris said. Also dpkg either
supports it or it does not, regardless of any Pre-Depends any package
might have. And we do something similar with Essential packages.
The only concern I can see with dpkg having the Pre-Depends is that
if we have a .deb with an unsupported compression, installation will
fail too late. But I don't think that's that important as this should
not happen on the archive anyway (those would get rejected).
Also just for reference, the main reason I didn't add the Pre-Depends to
dpkg in etch was because it was near a freeze (or already frozen, don't
remember now) and didn't want to destabilize d-i at that time. That was
probably a mistake, but I don't regret having played safe, there's
always time in the future to fix things.
regards,
guillem
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
