Re: Re: multiarch support and dpkg 2.0 design document
On Sun, May 14, 2006 at 05:19:29PM +0100, Scott James Remnant wrote:
> Matt's e-mail and the referenced PDF document are intended to start off
> those discussions.
>
> The PDF is the first time I've ever sat down and wrote, in one document,
> what I've been thinking about for the last couple of years. While I
> think it's pretty neat, I'm hoping others will be able to find holes or
> problems with it -- or improvements they can make.
I will just publicy note some thoughts about a new dpkg that came
up during discussions here on Debconf. Most of them probably only
become relevant in the next phase of planning, when actually thinking
about the implementation. But to have them recorded here can't actually
hurt (even if some of them might be really obvious).
* The new dpkg should be backwards-compatible with the current version
in that it can read "old" debs and handle them correctly. I currently
can see anything in the spec that would actually prevent us from
implenting it. (This might actually handled by a completly different
program that does the conversion but IMHO it should still be part of
dpkg).
* As I see it, the depency graph will get way more complex (mainly
because of the feature depencies but also because of the multiarch
support). Is there any danger that this will hurt us in term of
dependency processing and conflict resolution?
* Will it actually be feasible to have filters implemented in shell
that will be called for every file to process? We probably need
an API with these scripts so that actually need to be started only
once (per package probably). Otherwise the fork rate will probably
kill us, wont it?
* An argument against something I have said myself: Tuning the
diskspace usage of dpkg should become fairly easy with filters.
E.g. we could have an alternative conffile implementation that
doesn't save a copy of the file in the metadata if diskspace
is more important to a system than ease of conffile change
merging. Also things like deleting documentation and locale
files will be trivially possible then.
Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/
Reply to: