Re: kernel/d-i/security/release meeting at DebConf6
On Thu, May 25, 2006 at 05:10:57PM -0700, Steve Langasek wrote:
> On Tue, May 23, 2006 at 07:08:41PM +0200, Sven Luther wrote:
> > On Tue, May 23, 2006 at 09:47:08AM -0700, Steve Langasek wrote:
> > > On Mon, May 22, 2006 at 11:38:46PM +0200, Sven Luther wrote:
> > > > On Mon, May 22, 2006 at 01:52:47PM -0700, Steve Langasek wrote:
> > > > > > Perhaps we disable new kernel features for etch 1/2? e.g., limit new
> > > > > > feature to new hardware support. For example, we wouldn't want to
> > > > > > turn on something as drastic as preempt in a stable update.
>
> > > > > So how do you structure this? I would expect that updates limited to new
> > > > > hardware support shouldn't normally change the kernel ABI at all, which
> > > > > makes it hard to make both the old and new kernel versions available for
> > > > > installation.
>
> > > > > If it is a new kernel ABI (either because the version number has simply been
> > > > > changed on it, or for other reasons), what gets done with out-of-tree module
> > > > > packages?
>
> > > > If ever the new out-of-tree module and d-i kernel reunification is in place,
> > > > it will be easy enough to rebuild all packages which depend on the abi-changed
> > > > kernel.
>
> > > "rebuilding" them doesn't address the question of making them available for
> > > both old and new kernels. Since the assumption seems to be that etch 1/2
>
> > Well, they will obviously have the abi number embedded in their package name,
> > and a virtual package / provides who will handle the transition, so this
> > should be no real problem. It is a technology that is well proven and mastered
> > since years in debian. See the ocaml example.
>
> Er, the problem is that you're talking about keeping *two* sets of packages
> around. That implies two source packages; at least some members of the ftp
Well, it was my understanding that both those packages where living in a
differnt section, namely etch and etch-<whatever>, which would take care of
the problem. Failing that, it is easy enough to handle the problem in the same
way as we want to handle the sid/etch kernel dichotomy, in case we froze on a
2.6.16 kernel.
> team don't like having source packages building binaries that aren't
> mentioned in debian/control of the source package, and keeping one source
I fail to see the problem here.
> package for two kernel versions, one of them added at a later date and for
> an undetermined version, pretty definitely means that one set of these
> binaries aren't mentioned in debian/control of the current source package.
No, see above.
> The ftp team might be ok with making an exception here, I'm just saying
> that's a conversation to have *before* release instead of when it comes time
> to do etch 1/2 and people suddenly realize there's no infrastructure to
> fully support both kernels.
Ah, yes, i fully agree with you about that. Like most of the discussions we
are having now should have been handled last fall :)
> > > uses a different upstream kernel version than etch, to be able to continue
> > > providing security support for the etch versions it seems that you need a
> > > separate source package (or a whole new suite in dak complete with w-b
> > > support!) for any packages being rebuilt against the etch 1/2 kernel.
>
> > You need a source package, which will be able to generate its debian/control
> > semi-automatically, to adjust to the kernel abi change, yes. This is also
> > something we have done in the ocaml case recently. Needs some coordination and
> > policy for the out of tree modules, and maybe binNMUs who are able to
> > regenerate the debian/control in this way, but nothing otherwordly.
>
> Changing the list of packages in debian/control in the standard debian/rules
> targets is almost always something we treat as an RC bug; so binNMUs are
> definitely out.
Indeed. But why be so inflexible ? Why not see that there are some limited
cases where this is useful, and this is one of them. What is so definitively
wrong in this case ?
Also, the problem is not as you think, the idea is only to modify the
debian/control in an automated way in the source upload, so no, it would not
be binNMUs, but some kind of automated sourceNMUs.
We have the same problem in the ocaml case, and see what happened, despite our
care, some of the m68k packages where rebuilt with the older ocaml, the same
problem can happen here if we are not carefull and will cause a mess.
> Which means sourceful uploads, which means the binaries for the old kernel
> no longer correspond to the current source package, which means rene tags
> them as candidates for removal...
We can simply append some random tag to the new source-upload, or upload them
to a separate archive, and the problem goes away by itself.
There are always solution if there is the will to implement them :)
Friendly,
Sven Luther
Reply to: