On Thu, Aug 26, 2004 at 08:11:02PM -0300, Daniel Ruoso wrote: > Then create a Packages file for each section inside > main/contrib/non-free with the respective packages (the names could be > Packages.base, Package.gnome). The current big Packages file would not > be removed, keeping the compability with the current system. I have one giant question for you: how will you handle cross-sectional dependencies? If I just specify, for instance, the kde section, how will I get X installed? I see two possibilities: 1) The ftp-master scripts include in each sectional Packages file all dependent packages. This sucks because it is massive redundancy, but does at least leave the user with no broken dependencies. I would also imagine that no single Packages file is going to be less than about a quarter the size of the current one this way, because we tend to have very incestuous dependency paths, especially once you include Recommends: and Suggests:. I think you'd have to include at least Recommends: to ensure that things like aptitude continued to work correctly. 2) Increase the scope of your proposal to include specifying sectional dependencies between sections; for instance, if I asked for the kde section, I automatically get the x11 section's Packages file (either by value or by reference, as it were). This is nice because it reduces list bloat, but with the incestuous dependencies problem, you're probably going to be back to downloading at least half of the sections files (and, in all likelihood) almost all of them as soon as you pick one section. Remember that it only takes one dependency on a package in another section to have to pull in that entire section's Packages file... Another (minor) problem is that of degradation of the utility of programs like apt-cache, and installing packages using apt after finding them on p.d.o. But I think they're far smaller problems in the grand scheme of things, and the p.d.o problem could be solved by making it more obvious which sectional Packages file you need to be able to install the package. Please note that I'm not trying to destroy your idea; if we could do it, I think it would rock. But having spent a little time looking at the challenges I identified above, I'm not sure it's going to be such a net win. - Matt
Attachment:
signature.asc
Description: Digital signature