Re: Can we upload binaries using libc6 to hamm yet?
David Engel wrote:
[switching between libc5 and libc6 from *.deb files for making
binary packages for frozen and unstable].
>> That pain may also be a good thing in that
>> >it may encourage developers to concentrate on libc6.
>> So much for multiuser systems. Having to build as root is bad enough;
>> breaking everybody else's compilations in the meantime is much worse.
>A multiuser system probably shoudn't be running packages from
Hmm... I believe that I need to sum up what my requirements are; they
are spread out among too many mail messages, and possibly obscure
Assume I have a simple package called foo (no shared libs). I want
to release a bugfix into both bo and hamm, upgrading from
1.1-2 to 1.1-3 in the process.
Currently, all I have is a machine which other people also work on.
I can't bring it down to reboot, and I can't make other people's gcc
disappear. These other people may be compiling for other Linux
machines, which don't have libc6.
I want to provide a single source tree so that anybody who's running
pure bo or pure hamm can use "dpkg-buildpackage" on without a glitch.
If possible, I'd like to automate compilation to the point where
a single "dpkg-buildpackage" will build either a bo or hamm release,
depending on what magic I use.
After compilation, I would like to upload the source plus the
two packages to master, where the libc5 version should go into
bo and the libc6 version should go into hamm.
Problems I currently see:
1) I can't keep libc5-devel and libc6-devel on at the same time.
2) I need libc5-devel as the default.
3) If I generate both a bo and a hamm version, I don't know what names
I should use to differentiate them from each other when I upload
them to master. According to current schemes, both should be named
There are several possible solutions to 1) and 2) that I see:
- I build up a chrooted libc6-devel environment
- Somebody else builds my libc6 binary package for me.
- The libc6-devel environment is made to coexist with libc5-devel
Problem 3) is minor, and could be solved by releasing foo-1.1-3 into
frozen and foo-1.1.4 into unstable.
>Wouldn't you be concerned about other instabilities
Not when I'm only compiling. Also, of course, my own package is
bug-free by definition, since it also goes into frozen :-)
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, email@example.com.
The joy of engineering is to find a straight line on a double
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .