An extended proposal concerning Metapackages
While discussing Free-BSD style base system installation I'd come up with the
following suggestion:
\begin{quote}
Another issue is the division of Debian archives and development into
logical sections such that development gets a speed-up. In that respect, a
minimal change to the current organization is necessary. Otherwise, the
delays could even get longer. A good place to start is the profiles one
can choose for dselect at install time. It looks like the tasks you can
choose from are some arbitrary collections of packages. My proposal is throwing
out an is-a/part-of hierarchy into those tasks. That way, the class
diagram could account for the logical organization. The original system
that assigns each package a maintainer need not be changed. Suppose that
we allow the smallest leaf "task" to consist of 16 packages at most. Then
what is required will be to assign each task a "release-maintainer". I am
aware that it is pretty rough at the time I write (and think).
Nevertheless it might be a good start. (By leaf task, I mean those tasks
which don't contain instances of others) Those tasks which have others as
their parts or inherit from others may build a categorization that is both
sensible and manageable.
It seems to me that both part-of and is-a hierarchies (allowing multiple
inheritance) is necessary to break down Debian into comprehensible units.
In addition to this, such a categorization would be vertical to
main/contrib/non-free separation
\end{quote}
Now, what I speak of sounds pretty nice, but it is too theoretical to improve
upon. As I understand, the latest thread on metapackages have somewhat
approximated to what I'd suggested.
There are a number of facts to sort:
1) dpkg provides an is-a hierarchy: package x is a contrib, devel, required
package. That is a straightforward classification, but it is beginning to
become insufficient as the archive size grows.
2) Installation profiles/tasks/metapackages: these provide us with some
elementary part-of organization. However, the current approach does not scale
perfectly and it's likely that there's room for improvement.
3) A revision of package organization is quite beneficial: it can help users
(installation/menus/documentation) and developers (better co-ordination for
release work, better comprehension of the software in Debian).
4) The implementation must not require a major rewrite of related components.
(The new categorization must be vertical to the existing ones)
So, how do you achieve such functionality? I think that, while keywords are a
good aid for searching packages, they don't constitute a sufficently formal
categorization. We should aspire at constructing a rigorous OO model for
defining: what type a package/task is, and what the structure of a package/task
is.
Once categories/classes for the Debian archive are developed, it will be
possible to keep them up-to-date with little effort. What's more, all packages
in Debian that >>list the packages<< can make use of the tools/libs that have
been written. Defining the organization using OO methods will also help us
analyze the system in better detail. When the subsystems are designated
precisely, the system can be made more modular: the relationships between
modules can be properly determined, and improved upon.
How this should be implemented, I believe, is a question that isn't trivial. I
suspect it would be easier to use a language which already has support for OO
programming. ;) But also I think making it some kind of library would work
best. I'm afraid changes at both apt/dpkg level and
metapackages/dinstall/whatever level is necessary for ramping up to such
functionality.
Hope you don't flame me for not being a Debian developer and referring to
Debian developers as "us". However, I'd like to make all the thought
contribution possible if not as source code. I'm not blindly advocating an OO
design/implementation, but I suggest such a thing because it is the only right
way to go. Sometimes I feel a push for the design part of things, that's it.
__
Eray 'exa' Ozkural
CS, Bilkent Univ., Ankara
---------------------------------------------
This message was sent using Bilkent University
WEBMAIL Services http://mail.bilkent.edu.tr
Reply to: