Thomas Goirand <[email protected]> writes: > On 04/16/2013 03:58 AM, Joerg Jaspert wrote:
>> And we do consider a bit more here. Each and every package takes extra >> space in the various metadata places, like Packages (times number of >> architectures), our database, our various handling scripts of >> archive/testing/pts/bugs/whatnot. So we have to decide between an >> excessive split and something that makes sense. >> The nova packages consist[1] mostly of one file in /usr/bin with the >> size between 1500 and 3000 bytes, or worse - one file in /etc between >> 45 and 222 bytes - or even nothing (nova-volume). > I am on the side of Russ Allbery here. Ideally, as a developer, I > shouldn't have to worry about this, too much, and here is IMHO too much. > The infrastructure problems which Debian runs into shouldn't clash with > the convenience users either, to the point where Debian would be a very > special case with packaging different from other distro, and breaking > existing puppet scripts others are already maintaining (for Debian > and/or Ubuntu). I should probably be clearer here, since that's not actually my "side". :) I feel like this is a technical constraint, and I would always prefer to solve technical constraints instead of making people work around them. But as mentioned I don't have a good solution, and in the absence of a good solution, I think it's reasonable for packagers to work within that constraint or at least present a strong case (which I know you're trying to do later in your message) for why it shouldn't apply to their situation. This is typical of the sort of "fuzzy" kind of constraint where each additional package, in isolation, doesn't add significantly to the problem, and everyone can always make a case about why they're different, but if we accepted everyone's argument, we could get ourselves into increasing amounts of annoying trouble due to the size of the metadata. That said, I think one reasonable approach would be to find other big wins to significantly reduce the number of packages so that we don't have to worry as much about this. For example, finding a different way of handling debugging information would save enough space in the metadata to allow for quite a few sets of micropackages. It's unlikely that anyone actually disagrees with the ideal that the Debian infrastructure should be transparent to the users and packagers and just cope with whatever makes the most sense for them. The issue isn't disagreement over that ideal, but rather the decision of what to do when we don't have a technical solution that is currently fully capable of that ideal. >> The second part is something for a important bugreport >> - why do you presume to tell me I might not want qemu and uml, or >> qemu/kvm or whatever on one machine? I may not be able to run it at same >> time, but why may I not install them? > For testing, I would understand. But for going on production, it doesn't > make sense to install things for more than one hypervisor in a single > system. FWIW, I think the testing use case is important. This is the sort of constraint that I, as a Debian user, find really frustrating. I want to always be able to install a package to look at it, read the documentation, etc., even if the collection of packages I have installed doesn't make "sense," provided that there's no technical reason why those packages CANNOT be installed together. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
