[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit



Thomas Goirand <zigo@debian.org> 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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: