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

Re: Future of the linux udebs

On Fri, Feb 15, 2008 at 02:13:02PM -0200, Otavio Salvador wrote:
> Bastian Blank <waldi@debian.org> writes:
> > On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote:
> >>   - Is impossible to release d-i with a different kernel from sid
> >>     without a lot of hassle
> > d-i releases are built with testing udebs. Or do you mean something
> > else?
> Not during development cycle.

For development it is still possible to add different apt sources and
pull in whatever is wanted. Just pull unstable _and_ testing in and you
would not see the new version if testing was uptodate before.

> And the udebs on testing migrated to it from sid. I hope to not need
> to do uploads to t-p-u for d-i kernel ;-)

I still don't get you.

> >> linux-2.6/linux-modules-extra-2.6 would build the udebs using what
> >> list? Still using kernel-wedge?
> > They need to include the list themself, it will get version dependant.
> So your idea is to this list be placed inside each source package?

It's the only solution which will not kill new versions without code to
ignore udebs if the definitions are broken.

> This means kernel-wedge will be useless and _any_ change would be need
> to be done on kernel team svn.

The list needs to be available during build of the source package, it is
not possible to change them after that.

>                                This is a big regression from my POV
> since d-i team does need to be able to change the list by himself.

There are two sorts of changes:
- Modules got renamed/merged/removed.
  This will kill the build if not fixed, so we need to be able to do
  such changes on ourself.
- Modules got added.
  This may have an effect, but usualy it is new hardware support.

Now please explain why you _need_ to change that directly and produce
the following workflow
"mailto:d-i, commit, upload k-w, mailto:kernel, commit, upload l"
instead of
"mailto:kernel, commit, upload l".
This is a classical indirection.

>                                                             This looks
> logical since we'll be directly affected by it and the installer might
> break.

Everything might break.


Virtue is a relative term.
		-- Spock, "Friday's Child", stardate 3499.1

Attachment: signature.asc
Description: Digital signature

Reply to: