linux-mvl-dove_2.6.31-0.2_source.changes rejected

[Tim Gardner]

Steve Langasek wrote:
> On Wed, Aug 19, 2009 at 10:22:22AM -0600, Tim Gardner wrote:
>>> 'linux-libc-dev' is the one and only package name of this sort that we
>>> should have in the archive.  It is the package that fulfills the libc6-dev
>>> package's dependencies, and there should be one and only one of this package
>>> per architecture - we do not need or want per-flavor versions of this
>>> package.
> 
>>> Please correct this and reupload.
> 
>> Even though its still in debian/control, the build doesn't actually
>> produce a libc-dev package (though you wouldn' know that until its too
>> late). I'll strip it out of the control file for the next upload.
> 
> Ok, thanks.
> 
>>> Given that all kernel flavor names will always be unique within an
>>> architecture (they must be since the kernel image packages are named
>>> linux-image-$kvers-$abi-$flavor), I believe it's preferable to name all of
>>> the header packages linux-headers-$kvers-$abi-$flavor as well regardless of
>>> which source package they come from.  Oliver has noted in discussion that
>>> there is code in livecd-rootfs that looks for the standard package name
>>> pattern linux-headers-2*:
> 
>>>      chroot ${ROOT} dpkg -l linux-headers-2\* | grep ^i | awk '{print $2}' \
>>>          > livecd.${FSS}.manifest-headers
> 
>>> So these linux-mvl-dove-headers-* packages won't match the pattern and will
>>> be missed.
> 
>>> Unlike the linux-libc-dev issue, I don't think this part is a blocker for
>>> acceptance into the archive, but I do think it should be changed when you
>>> have a chance.
> 
>> I was concerned about package name collisions across the various kernels
>> if I chose a generic naming scheme. However, I guess the solution is to
>> start with an ABI number that is unlikely to collide with any other
>> kernels. Won't it be a bit confusing to see multiple headers packages
>> that differ _only_ in the ABI number? The linux-headers flavour packages
>> will be obvious, but the *_all* packages will all look the same.
> 
>> linux-headers-2.6.31-1_2.6.31-1.3_all.deb
>> linux-headers-2.6.31-10_2.6.31-10.3_all.deb
> 
> So with regards to these packages, I don't think the armel flavors should be
> depending on them or referencing them at all.  The reason the
> "linux-headers-$kvers-$abi" packages are there is to avoid having to
> duplicate its contents between flavors; but with one kernel flavor per
> source package in the case of armel, there isn't actually anything to share.
> So merging all the contents into a single
> "linux-headers-$kvers-$abi-$flavor" package should address this.
> 
> But of course that's more work than just renaming the package, so I'm in no
> hurry on this.  As I said, I don't consider this one a blocker for clearing
> NEW.
> 
> Cheers,

The reason that I feel like I have to have separate
linux-headers-*_all.deb packages (and duplicate content) is that I'm
dealing with multiple, incompatible source code bases. Marvell and
Freescale don't play well upstream, so they've chose divergent paths.
Rather then try to jam them together, we've chosen to just have a
separate source code base for each OEM. Obviously, there are a bunch of
header files that are unique to each vendor, while the bulk of the
headers are the same.

So, in order to avoid namespace collisions, while still providing the
normal package naming, I've chosen to distinguish these source code
packages using disparate ABI sequences. Freescale starts at 100, Marvell
at 200, the next unique source base at 300, etc. Hopefully that'll be
sufficient to support the installer folks.

rtg
-- 
Tim Gardner tim.gardner at canonical.com