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