Hi
As some of you know I am working on cross compiler packages for Ubuntu. Those of you who know what Emdebian is probably use their repositories for such stuff. Thats ok - I just want to share with you what my job will bring in near future and what I have done in last 3 months.
Since 26th April I am working for Canonical as part of Linaro project. Due to my six years of OpenEmbedded experience I became part of Toolchain Working Group and started work on packaging. Specification etc are listed on blueprint page:
https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers
I started with reviewing gcc-4.4/4.5 and binutils packaging rules and merged them as much as possible to get rid of *-cross.mk files which went bitrot a bit. As result we got packages with debug versions of libraries, dependencies are proper and as a bonus we got libmudflap cross compiled in case someone needs it.
Currently I am working on bootstraping cross compiler without using dpkg-cross converted packages (aka Emdebian way). I got it working with Ubuntu Maverick versions and published all required patches in bugs linked to my blueprint. Maybe it is not easy to recreate but should work when you will try.
To make it possible I also have to alter contents of *-source binary packages from binutils/eglibc/gcc/linux to have a possibility to reuse their packaging rules in new $ARCH-cross-compiler package on which I will work in next weeks.
And here I have a problem. How much of debian/ directory should be provided in *-source binary packages? Minimal set just to be able to call "dpkg- buildpackage -b" and get wanted output or rather everything just in case?
Why new $ARCH-cross-compiler package instead of Emdebian way? Think about buildd and how they work - nothing can be done manually there so we need to automate whole procedure.
Regards,
On Tue, Jul 27, 2010, Marcin Juszkiewicz wrote:
And here I have a problem. How much of debian/ directory should be provided in *-source binary packages? Minimal set just to be able to call "dpkg- buildpackage -b" and get wanted output or rather everything just in case?
So currently, various -source packages do various things; some -source packages ship the upstream tarball + patches separately, other ship a patched upstream tarball, and in one case it's upstream tarball + patches + some rules file to apply them.
I personally find that very inelegant and inconsistent.
Since we can't build-depend on the "source of this package", what I would find elegant and consistent would be to ship the .dsc + any files it references in the -source package. This is guaranteed to convey the full source, we'd have an unified interface for unpacking (dpkg-source -x), and we could call the build as usual. However, there is no guarantee that the .dsc is in ../ during the build of toolchain packages. In my experience, it is there though.
What I'd recommend is copying over ../$source_$version.dsc and files it references into the -source binary package; if someone isn't happy about reading from ../, or has a better idea, they will speak up :-) [ It's of course possible to recreate a similar .dsc by running dpkg-source on a copy of ./, but that would be a bit inefficient, and would create a slightly different .dsc, albeit with approaching contents. ]
Cheers,
Dnia wtorek, 27 lipca 2010 o 14:03:57 Loïc Minier napisał(a):
On Tue, Jul 27, 2010, Marcin Juszkiewicz wrote:
And here I have a problem. How much of debian/ directory should be provided in *-source binary packages? Minimal set just to be able to call "dpkg- buildpackage -b" and get wanted output or rather everything just in case?
So currently, various -source packages do various things; some -source packages ship the upstream tarball + patches separately, other ship a patched upstream tarball, and in one case it's upstream tarball
- patches + some rules file to apply them.
You forgot about binutils which ships patched sources tarball + patches.
I personally find that very inelegant and inconsistent.
Since we can't build-depend on the "source of this package", what I would find elegant and consistent would be to ship the .dsc + any files it references in the -source package. This is guaranteed to convey the full source, we'd have an unified interface for unpacking (dpkg-source -x), and we could call the build as usual. However, there is no guarantee that the .dsc is in ../ during the build of toolchain packages. In my experience, it is there though.
Probably depends on a way of building it. In my builds I did lot of "dpkg-source -x ../../../source/gcc-4.4<TAB>.dsc" calls.
What I'd recommend is copying over ../$source_$version.dsc and files it references into the -source binary package; if someone isn't happy about reading from ../, or has a better idea, they will speak up :-)
So we are back at my question again.
Regards,
Hello,
2010/7/27 Marcin Juszkiewicz marcin.juszkiewicz@linaro.org:
Dnia wtorek, 27 lipca 2010 o 14:03:57 Loïc Minier napisał(a):
On Tue, Jul 27, 2010, Marcin Juszkiewicz wrote:
And here I have a problem. How much of debian/ directory should be provided in *-source binary packages? Minimal set just to be able to call "dpkg- buildpackage -b" and get wanted output or rather everything just in case?
So currently, various -source packages do various things; some -source packages ship the upstream tarball + patches separately, other ship a patched upstream tarball, and in one case it's upstream tarball + patches + some rules file to apply them.
You forgot about binutils which ships patched sources tarball + patches.
I personally find that very inelegant and inconsistent.
+1
It would be good to amend Debian policy in this respect - having a consistent format for -source packages - if you find it appropriate. I would even go further and I would try to have all (build-)essential packages provide a consistent -source package, for easier work on bootstrapping $distribution from source.
What I'd recommend is copying over ../$source_$version.dsc and files it references into the -source binary package; if someone isn't happy about reading from ../, or has a better idea, they will speak up :-)
If there is no standardized way of doing so, anything you do might conflict with others work and it would probably be considered as a hack.
Best regards, :-)
On Tue, Jul 27, 2010, Hector Oron wrote:
I would even go further and I would try to have all (build-)essential packages provide a consistent -source package, for easier work on bootstrapping $distribution from source.
I'm not sure build-essential relates; the reason for pushing for the cross-toolchain effort is because we need to bootstrap them on buildds for consumption by end users. But to bootstrap an architecture from scratch should rather be an extension of our buildd software, or a new software working from the archive -- doesn't need to happen within a regular build.
Hello,
On Wed, Jul 28, 2010 at 12:16:31AM +0200, Loïc Minier wrote:
On Tue, Jul 27, 2010, Hector Oron wrote:
I would even go further and I would try to have all (build-)essential packages provide a consistent -source package, for easier work on bootstrapping $distribution from source.
I'm not sure build-essential relates; the reason for pushing for the cross-toolchain effort is because we need to bootstrap them on buildds for consumption by end users. But to bootstrap an architecture from scratch should rather be an extension of our buildd software, or a new software working from the archive -- doesn't need to happen within a regular build.
If you want to extend buildd software to do that, I'll tell you, it is not going to work for several reasons, and Debian is not kind enough to add a new control field for bootstrap depends which means they'll have to maintain and bootstraps does not happen so often.
The same approach can be done by build depending on -source packages and replacing debian/ directory into whatever you, me or anybody else would feel like it. For example, busybox package, how would you like it for this week? Emdebian-crush probably does not need the same as d-i config, nor Emdebian-baked, nor Linaro, nor $any_other_vendor :)
Best regards,
Hello Marcin,
On Tue, Jul 27, 2010 at 01:06:15PM +0200, Marcin Juszkiewicz wrote:
To make it possible I also have to alter contents of *-source binary packages from binutils/eglibc/gcc/linux to have a possibility to reuse their packaging rules in new $ARCH-cross-compiler package on which I will work in next weeks.
RE: $ARCH-cross-compiler package
We already had that approach years ago... http://packages.qa.debian.org/t/toolchain-source.html
Not sure what is your thought, but please, do not get into already passed errors again.
Cheers,
Dnia środa, 28 lipca 2010 o 19:16:42 Hector Oron napisał(a):
Hello Marcin,
On Tue, Jul 27, 2010 at 01:06:15PM +0200, Marcin Juszkiewicz wrote:
To make it possible I also have to alter contents of *-source binary packages from binutils/eglibc/gcc/linux to have a possibility to reuse their packaging rules in new $ARCH-cross-compiler package on which I will work in next weeks.
RE: $ARCH-cross-compiler package
We already had that approach years ago... http://packages.qa.debian.org/t/toolchain-source.html
Not sure what is your thought, but please, do not get into already passed errors again.
No, I do not want to go that way. Too much wasted time on merging all changes from gcc/binutils/linux/eglibc. I will use *-source binary packages to get sources/patches/packaging rules for each of components.
Regards,
linaro-toolchain@lists.linaro.org
-
Hector Oron -
Loïc Minier -
Marcin Juszkiewicz