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

Re: linux-2.6 - subarch and patches

On Wed, 3 Aug 2005, Bastian Blank wrote:


Hi folks

linux-2.6 currently "supports" something called subarch. It should be
used for incompatible patches. This is needed for m68k and I think mips.

Problems with this
- mostly unimplemented,
I can't say that I have extensively tested the subarch cases, but I definitely had it in mind, and I'd rather describe its state as "very poorly tested" than "mostly unimplemented" :-) 


- namingschema differs from anything else: linux-image-$subarch-2.6-$flavour.

Proposal:
Replace with patch definitions.

- Each arch may specify an architectury specific patch, each image
 package may specify another patch, it may shared between more than one
 image.


There is actually code for that in $(kdir) target in debian/Makefile:

patches  := $(wildcard patches-arch/$(subarch).*)
patches  += $(wildcard patches-arch/$(subarch)_*)
patches  += $(wildcard patches-arch/$(karch).*)
patches  += $(wildcard patches-arch/$(karch)_*)
patches  := $(strip $(patches))
[...]
$(kdir): post-install-$(subarch) $(wildcard templates/control.*.in)
[...]
        if [ -n '$(patches)' ]; then                    \
          cd $(tkdir);                                  \
          cat $(addprefix ../,$(patches)) | patch -p1;  \
        fi
Definitely there is room for improvement, but your proposal is (at least partially) implemented. 


- Generated packages:
 - Patches:
   - linux-patch-debian-$version (the same than now)
   - linux-patch-debian-$version-$arch
   - linux-patch-debian-$version-$arch-$name
With the common source package I see absolutely no reason to split the patches up. And the code which will collect all the arch/subarch specific patches and put it into a single linux-patch-debian package is already there. 


 - Header:
   Any of the package contains the same, just with the patches applied.
That is also taken into account already: the subarch-specific header packages are built (or rather, would be built) from the patched tree, so all the header files are correct. 


   If we have want to code something more, we may produce packages
   which just links most of the files to the more generic version.
   - linux-headers-$version-$abiname (as known)
   - linux-headers-$version-$abiname-$arch
   - linux-headers-$version-$abiname-$arch-$name
I don't have any objections to this naming scheme (generally, I don't care about naming so much :-). The only thing which in my opinion _must_ be guaranteed, is that running 

apt-get install linux-headers-$(uname -r)
will install the full set of packages for the currently running kernel. If you have a clear picture on how to do that in your naming scheme, just go ahead and make the necessary changes. 


- linux-header-$version-$abiname-$flavour depends against the main
 header package which the correct patches.

Bastian
It turns out that I will not be available on Saturday to discuss these things, sorry about that. Hopefully we can talk on Sunday. 

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC
Reply to: