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

Re: Future of the linux udebs

On Fri, Feb 15, 2008 at 04:40:47PM -0200, Otavio Salvador wrote:
> If a unwanted kernel is uploaded to sid and we wanted to update the
> udebs, for a release or something, we would end up doing it
> t-p-u. This would be done with minor testing and possible breaking
> lenny installer.

So? If we need to update the kernel themself, it is also needed.

> >> 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.
> Didn get you here. Could you elaborate it a bit?

The list contains module X. This module got removed. What should happen
with the build?
- Fail silent. Ignore the error and don't output any udebs.
- Fail loud.

The first variant needs to be used if the list is included from an
external source if it should not break it complete. I won't implement it
because the build output is not longer reproducible.

> > The list needs to be available during build of the source package, it is
> > not possible to change them after that.
> Sure. But it could be available from kernel-wedge or something?

It introduces an out-of-date problem. You can only force the
availability of a new enough version by an explicit build-dep. To be
exact, it needs to be a = dep.

>                                                                 This
> would allow us to keep control about what would be end in d-i kernel
> modules packages.

We have to process it anyway and will be able to change it in any way we
want. This is called trust.

> If this could be done from a d-i package (k-w or anything) it gives us
> a cannonical place to look at and don't force us to follow another
> commit mailing list to get the need information.

You would be forced to read build logs for failures and handle them on
your own, because we don't like breakages and would disable the build
completely, which does not get as anything except more possible problems.

> > Everything might break.
> And we need to try to avoid it as possible.

Yes. The solution is called "test", either programmatic (which is not
that easy in this case) or manual.


Killing is stupid; useless!
		-- McCoy, "A Private Little War", stardate 4211.8

Attachment: signature.asc
Description: Digital signature

Reply to: