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

Re: ia64 added to svn



On Tue, Jul 27, 2004 at 06:10:42PM +0200, Jens Schmalzing wrote:
> Hi,
> 
> Sven Luther writes:
> 
> > And, do you have any other solution for not getting the powerpc
> > package to break once kernel-source-2.6.7-4 is uploaded ?
> 
> The immediate solution is of course to remove the pegasos patch from
> kernel-source and leave it in kernel-patch-powerpc until it enters

Well. Sure, but how are you going to do it then, when kernel-source 2.6.7-4
enters unstable and a user rebuilds a powerpc kernel with the patches -> you
loose pegasos support and the g4-errata fix.

But i understand your security concern, a better solution is needed, since
like that you loose both why. That said, if you do a security upgrade, like i
have done in the past, you need to rebuild the per arch kernels anyway, and
thus modify the control file to build-depend on the kernel-source version that
has the security fix or higher. In this light, bumping the kernel source
version would be ok anyway, and better than having a FTBFS as we would have in
the current system.

The right thing would probably to have the per arch kernel-powerpc have a
kernel-source-version file or something such, which contains the exact
kernel-source version which was used to build this package, and have the
debian/rules use it to generate a strict build-dependency  and have it
applying the right kernel-source patch.

This way, when a security build is pending, you update the version in this
file, and simply rebuild, everything is fine, provided the patches don't
conflict. It could even be automated if the remaining per arch packages where
using the same infrastructure.

> upstream.  In the long run, the apply script in kernel-patch-powerpc
> could detect already applied patches and skip them.
> 
> > > I'm just not willing to discuss your pipedreams to death.  An email
> > > asking me to do the build and upload would have been enough.
> > 
> > Thanks all the same for team work.  Do you really think we can
> > continue to work like that ?
> 
> Sure.

Well, i have serious troubles with it and your despreciating attitude toward
me. I was wrong about the marvell thing, sure, altough there would have been
no harm in having the older driver in for the week or two while the new one
was worked on, but this is no reason to continue threating me like this.

> > You didn't even check in your above mentioned changes into svn,
> 
> Oops.  Done.

Hehe.

> > And you are also actively opposing a 2.6 based miboot using
> > debian-installer, which means we will be saddled with 2.4 kernels
> > for oldworld miboot install, which i really wanted to avoid.
> 
> I don't think that anybody who has his senses together would at this
> point remove the 2.4 kernels for an entire platform.  I have no

We are speaking of making 2.6 it the default, not removing 2.4. You don't care
about 2.4, christoph don't care about 2.4, i care less everyday about 2.4, so
who in his right mind would still propose to a debian/sarge user a 2.4 kernel
by default.

> problem with leaving 2.4 kernels in Debian for the forseeable future
> and don't see the benefit of hastily pushing for temporary solutions.

There is no time anymore, the base freeze is next week, and the
debian-installer release also. By having a solution in over no solution at
all, it would have allowed us to fine tune 2.6 miboot floppies, but right now,
your inaction, and even opposition, has condemned us to keep 2.4 miboot
floppies. And thus have a category of users for which we will have a kernel
installed by default who none of the kernel maintainers care about, and which
we really would not have the users install.

> Especially with the upcoming freeze and release.

Yeah. When was it i asked you for a oldworld/miboot floppy the first time ? If
you had acted then, we would not be with our back to the wall right now.

Friendly,

Sven Luther



Reply to: