Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i

[Sven Luther <sven.luther@wanadoo.fr>]

On Mon, Nov 06, 2006 at 09:27:10AM -0200, Otavio Salvador wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
> 
> >> > Yeah. You know we stopped doing this kind of stuff for the kernel package over
> >> > a year ago, and probably for a reason, don't you think ? 
> >> 
> >> We stopped doing that for kernel packages. The problem here is that,
> >> without doing that the binaries will stay but without source
> >> code... that will be a GPL violation AFAIK.
> >
> > Indeedm which is why the .udebs should be built from the kernel packages
> > directly, but then i will be lapidated for suggesting this again. :)
> >
> >> Or I didn't understand what you're proposing or I don't think your
> >> problem will source the GPL violation of lack of source code of
> >> binaries. That's what I don't think it'll solve.
> >
> > No, to the contrary, it will solve the problem.
> >
> > Since for every kernel abi number, we will store both the .debs and the .udebs
> > into a separate archive, instead of the current situation, so all .debs will
> > always be together with their source. The only problem would be for .udeb
> > package not being rebuilt with the latest kernel of an abi-serie, but this
> > could easily be fixed, and like said, building the .udebs from the kernel
> > package will solve that.
> >
> > We will only advertize some of those kernels as officially supported, and the
> > rest will act a bit like the snapshot.debian.net stuff, and would not even
> > need to be available on all mirrors or something.
> >
> > Like said, a clean and neat, complete solution, which just need a bit of work
> > to make happen.
> 
> I like the idea while I keep in my mind that Joey had some reasons to
> dislike the udeb building from kernel source. I don't remember which

He dislikes it, because he then will have less control over the .udeb content.
But the one archive-per-kernel-abi idea is not dependent on building the
.udebs from the linux-2.6 source package, so this doesn't apply here.

> was the reasons but would be good if you review his posts and check if
> those problems will still happen if we implement your proposal.

I will expose these ideas at fosdem, during a conference, and we can have a
chat afterward. It is etch+1 material anyway. And then we can retalk about
them at debconf'07.

> Other problem that I see is how we'll say:
> 
>  version X is supported
>  version Y isn't supported, use at your own risk

Well, the supported versions may be pulled in into the sarge/etch/sid relese
files, the per-version only being around for development cycles.

The d-i image, could even go as far as noticing that you are using a kernel
which is not in the main releases, informing the user that he may be using an
out-dated image, and then looking at the per-abi archives

> that can stay to be messy.

Not if done right, and as said, this plan has the potential to be a clean and
neat implementation, where everyone will say afterward, how did we ever manage
it before.

The real interogation are on the ftp-master side. 

Friendly,

Sven Luther