Re: bits from the release team
On Wed, Jan 04, 2006 at 12:13:37AM +0100, Frans Pop wrote:
> On Tuesday 03 January 2006 23:52, Sven Luther wrote:
> > The current proposal is about simply using the same .udeb organisation
> > and move it inside the linux-2.6 common package, which is something
> > that works out just fine for ubuntu even, but which the current
> > linux-2.6 common package infrastructure could also handle.
> So, when can we expect a coherent, full proposal (with overview of
> benefits, possible pitfalls, things that need to be worked out further,
> and so on) on this in a dedicated mail on a new thread to the relevant
> mailing lists, so we can actually comment on it instead of only seeing a
> rough outline mentioned every so often as part of a flame?
The linux-2.6 package will propose a solution which will produce the *EXACT
SAME* set of .udebs as with the current kernel-wedge solution, and will be
more easy to maintain in a more automated way, and integrated with the rest of
the linux-2.6 kernel, so porters only need to do the work once in a single
> (Without the "current method sucks" comments please; saying "I think the
> current situation could be improved by..." is much more likely to get
> positive reactions.)
This is not my past experience though, and the current method sucks, this is a
fact, i as powerpc porter of d-i have to live with, so why should i not be
allowed to express my opinion about this ?
> > The only
> > reason i saw against this was a mail from joeyh mentioning ease of
> > moving modules around inside .udebs, and that this would be easier
> > under the d-i umbrella than if it is inside the kernel, and naturally
> > the old sarge-time brokeness in the archive infrastructure, which is
> > presumably fixed by now, or should be fixed for etch.
> You forget the argument that when kernel udebs are maintained within d-i,
> we will be much more likely to spot changes in them as a possible cause
> of breakage when installation-reports come in.
well, if the only thing you are afraid about is documentation, we shall
provide you with this information in a way most suitable. All this can and and
will be easily automated and presented upon you on a platter, which is not the
case with the current kernel-wedge situation, where the i386 .udebs and
kernel-wedge are updated and the rest of the ports left out in the cold
without any kind of info about possible breakage already fixed on i386, thanks
you very much, so two weights two measures, right ?