Erik Schanze <schan...@gmx.de> writes:
> Hi mentors,
>
> I have a question regarding repacking and hope you could give me some
> suggestions.
>
> I'd like to run a special x86 based device with Debian.
> I could use most of the common Debian packages, but I have to repack some of
> them
> for the use on this device. The packages will be provided and maintained
> for the devices on a special repository server.
>
> First I have to repack Linux kernel package to apply a custom configuration
> and additional patches.
> I see 2 possibilities.
> 1. Change the config and add patches in Linux source package, bump the
> Version with an epoch and build the binary package for my platform.
> Upgrades with Debian kernel packages should be prevented by the epoch.
> But the custom source and binary package has the same file name as the
> Debian ones, so you could not see that it is different easily.
Not good. While unlikely Debian could add an epoch and then you back to
your problem again. Also people could install your kernel on their no
"myDevice" hardware. From the package name it would be unclear that you
altered the config.
> 2. Extent the Linux source package with a new binary target for my platform
> e. g. linux-image-2.6.26-2-686-myDevice,
> but then I have to deal with Linux meta packages also
> (like linux-image-2.6-686 and linux-image-686).
That is much better in my opinion. For compiling speed and archive side
reasons you probably want to also remove the other config from your
linux-2.6 source. No need to have a bunch of usefull kernels in your
archive that would only confuse users.
> Second I have to repack some packages to remove some files from the package,
> because 3rd party software provides these files also and I have to prevent
> a clash. I have to repack these packages without these files, depending on
> a package with the 3rd party software which has the (adapted) files.
> I see the 2 possibilities above also.
> Or is there any other (better) way?
A while back, at an emdebian meeting in spain, we worked out a draft for
DEB_VENDOR, which would allow you to submit a patch to Debian that would
for example drop those files if DEB_VENDOR=myDevice was specified. I
haven't seen much about it implementation wise since but that was what
we came up with as best solution to your kind of problem (The problem of
vendors needing a subset of Debian compiled a little bit differently).
But I'm not sure a couple of duplicate files need that really. Why not
have the 3rd party packages add a "Replaces: debian-package-with-file"
or use dpkg-divert?
> I'm a bit lost to find a way which is compatible to Debian archive and
> packages that are easy to maintain and to follow Debian versions
> (mostly security fixes).
You should set up a sync script that fetches new sources and an
autobuilder that compiles them with any patch you have for the
source. Ubuntu has experience with that so maybe they can help.
> Hope anyone could help.
>
>
> Kind regards,
>
> Erik
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
