Re: 2.6.12 in volatile?
On Mon, Aug 15, 2005 at 10:29:00AM +0900, Horms wrote:
> On Fri, Aug 12, 2005 at 04:09:29PM +0200, Andreas Barth wrote:
> > * Horms (horms@debian.org) [050811 23:46]:
> > > On Wed, Aug 10, 2005 at 07:56:00AM +0200, Sven Luther wrote:
> >
> > > > > The latter, according to volatile policy (... must be autobuildable
> > > > > from the same release...).
> >
> > > Is that part of the policy intended preclude providing an update to
> > > kernel-package (or any other tool) that might be needed? It would
> > > be good to clarify that.
> >
> > Technically, we consider sarge+sarge/security+sarge/volatile as the
> > release we build volatile packages in. However, as build-depending on a
> > newer version is _also_ a packaging change, there needs to be a really
> > good reason for that (as for any packaging change).
>
> Thanks for the clarification.
Well, the changes are needed since the state of pre-sarge powerpc targets in
kernel-packages where inadapted and buggy as hell, so we had to do some
post-processing in the post-install. As he new packaging system uses its own
post-install, and in order to not have the user-generated packages differ from
the official ones, we decided to bring the logic into kernel-package and the
kernel source itself.
The change is a couple of lines of diff against the rules file, which can
easily be backported, which introduces two new subarches which are used by the
new kernel packaging.
As such, the patch is fully backward compatible, and there is zero risk
involved in breakage or something (anyone doubting this is free to look at the
code and prove me the contrary :).
> > > Another solution I thought of would be to bundle kernel-package inside
> > > linux-2.6 (for volatile/sarge) somewhere. Though I am not sure
> > > how much surgery would be required to relocate kernel-package.
> >
> > Well, that's obviously worse.
>
> Perhaps.
>
> It turns out in this case that the change required is quite small.
> So we could just carry that change inside the linux-2.6 package
> for volatile, rather than include it in a build-depending update.
> Though the feeling I got from Svenl, which I agree with, is that
> the latter is prefered.
I have some doubts about the cleanliness of the external patch method and if
we can easily divert the rules file from make-kpkg to our own one. I strongly
recomend not to go this hacky way just because of some bureaucratic rules
preventing us to do the right thing, and patching kernel-package. Let's use
common sense over dogma and rigidity, ok ?
Friendly,
Sven Luther
Reply to: