Re: Debian kernel maintainter takeover
* Christian T. Steigies (cts@debian.org) [040517 12:10]:
> On Mon, May 17, 2004 at 10:02:03AM +0200, Andreas Barth wrote:
> > * Francesco P. Lovergine (frankie@debian.org) [040517 09:55]:
> > > On Sun, May 16, 2004 at 09:34:46AM +0200, Andreas Barth wrote:
> >
> > > > One other change I'd like to see ASAP is to having a "first class
> > > > architecture set" instead of a individual kernel for i386 and alpha
> > > > (and possible more to add to this).
> >
> > > Could you please explain this better? What's s first class arch set?
> > see http://lists.debian.org/debian-devel/2004/04/msg06531.html for an
^^^^^^^^^^^^
> > explanaition.
> Oh... how come I've never seen this before? I thought I subscribed to
> debian-kernel.
Debian-devel, in the thread about security updates.
> I don't know why everybody is picking on m68k,
I'm sorry that I seem to picking on m68k. Please take it from me that
I don't (or at least: don't intend to), and that I realize that the
kernel maintainership on m68k is quite more difficult than on i386.
All I wish is that we reduce the number of source packages for the
kernel, to ease the load for the security team. I'd be happy if as
many architectures as possible are in the fast set - however, as a
i386-only-user I just don't feel myself knowing enough to tell which
architectures could be added to the fast set. The i386 and alpha
(above) were taken from Herberts mail. Furthermore, I always consider
it a good idea to start small, and add one architecture after the
other to the set, so that we handle that right. And, of course, as far
as I can see, i386 should be the first one in the fast set, as the
architecture-patch is not existent.
As far as I understood your mail
> I have been working on combining all m68k kernel-image packages into one, I
> guess I could even merge the kernel-patch and kernel-header package into
> this one package. The big drawback is, it will take a long time to build
> one big package. If I have a new patch to fix one driver for one subarch,
> it does not make sense to rebuild the kernel-images for the other five
> subarches as well, but if security requires this, we could do it. Of course
> it might be faster if we would run individual kernel builds on three
> machines, but if it is urgent, I could always switch back to indivual image
> builds.
m68k seems to have a rather difficult setup. So, for me, this
indicates that we should start with an easier arch for the first
multiarch-source-package. Please don't understand this as any picking
on m68k, but just as trying to start with a simple case, and extend
this after managing this sucessfuly to a more difficult one. And of
course, my opinion on this might be rather wrong. So, please tell me
if I have misunderstandings of the different archs.
> So my biggest problem is (besides from some packaging problems I still have
> with six kernel-images), how are conflicting arch specific patches going to
> be handled?
in worst case like
#ifdef _DEBARCH_M68K_FIRSTSUBARCH
....
#else
....
#endif
(please don't take the name of the define serious)
For:
> The big drawback is, it will take a long time to build
> one big package. If I have a new patch to fix one driver for one subarch,
> it does not make sense to rebuild the kernel-images for the other five
> subarches as well, but if security requires this, we could do it. Of course
> it might be faster if we would run individual kernel builds on three
> machines, but if it is urgent, I could always switch back to indivual image
> builds.
The security team requires us to have as less kernel source packages
as possible, and that every binary package in sarge can be reproduced
by the appropriate source package in sarge, with help of other binary
packages. I think that we should help them as much as possible.
Again: No picking on any architecture is intended by me. I'm sorry if
any of my mail could be read in this way.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: