On Mon, Nov 06, 2006 at 09:27:10AM -0200, Otavio Salvador wrote: > Sven Luther <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
