Re: Re: multiarch support and dpkg 2.0 design document
On Sun, May 14, 2006 at 05:19:29PM +0100, Scott James Remnant wrote:
> > But is there someone stepping up to lead efforts to really start
> > developing dpkg 2? I've not seen something happening to that effect
> > on this list.
> >
> Well, the first sensible step would be to discuss whether such a thing
> would be desired; and if so, the basic form of a new package manager.
>
> Matt's e-mail and the referenced PDF document are intended to start off
> those discussions.
Well, the desire for a dpkg sucessor is a difficult thing to define
(e.g. do you mean the desire to program it or to use it ;)
But the fact is that dpkg has some longstanding limitations and quirks
that apparantly nobody is able and/or willing to fix in its current
form/codebase. And it's not like there weren't some that tried :)
> 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.
One thing that I wondered about while reading the document are the
restriction on what filters and classes can do. As I understand it,
filters are intended to work on the meta-data and classes are intended
to reflect that meta-data in the system.
But lets take the proposed implementation of dpkg-divert in filters
as an example: Wouldn't that require that the filter moves a file
from a different package around (to divert it away) and changes it
meta-data (to reflect the move). Is a filter allowed to do such
things?
One other question that came up was about the resource usage to
be expected from such a new version. Since the amount of meta-data
will probably increase dramatically (by the stored conffiles, etc)
So an interesting question might be how good one can accomodate
people with rather small systems so that dpkg doesn't take a significant
amount of their space.
The memory usage probably can also expected to increase, e.g. since
the dependency graph gets a lot more complex with all the "features",
and arch dependencies. Since the current version is already a real
resource-hog in that regard, special care should be taken to not
increase that in order of magnitudes or at least give people a chance to
tweak it for their needs.
> Once that discussion's over, or if there is no resulting discussion (my
> ideas are that perfect? :p), then I guess that's the time to talk about
> details of implementation and get a team together.
>
> The members of that team may or may not depend, for example, on whether
> that work is funded or driven by HP and/or Canonical -- on that I don't
> have any idea or say, being just a humble code monkey :p
My primary concern in this matter is that the project remains open
and allows contribution from a broad group of people even if some
company decides to fund and/or lead it. This is of course on the
one hand a personal concern because I'm very interested in participating
in such an effort but also a general one since (IMHO, anyway) the
biggest chance of "creating" a lot of people knowledgable of the codebase
is by getting them to participate in the project early.
Gruesse,
--
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/
Reply to: