Re: [multiarch] Proposal for *-dev packages
Anthony DeRobertis <asd@suespammers.org> writes:
> On Jan 14, 2004, at 13:26, Goswin von Brederlow wrote:
>
> > When installing packages of multiple archs some packages will contain
> > the same files, which is a problem of cause.
>
> ... Now that is a PITA ...
> >
> > The later [Architecture: <arch>] are a problem for multiarch
> > systems. To compile 32 bit
>
> > programms the 32bit flavour must be installed and to compile 64bit
> > programms the 64bit flavour. Overlaps in the files make it complicated
> > to install both.
>
> But you don't need to install both. You install the i386 one when
> doing the 32-bit build, and the amd64 one when doing the 64-bit build.
Some packages (libc) need to be installed for both 32 bit and 64 bit
at least on the build (to compile gcc).
Other could do with conflicting -dev packages. But the majority of
people I talked to so far would like to havethem installed in parallel
instead of having to purge and reinstall them each time they compile
for a different bit depth.
Just consider compiling a benchmark that tests 32 bit and 64 bit
support. That would be hell.
> > Both having the same name would be a problem in dpkg,
> > both having different names would mean changing basically every source
> > package in Debian.
>
> I thought that having, e.g., coreutils:amd64 and coreutils:i386
> installed at the same time was impossible (without --force, of
> course[0]). So having the same name wouldn't be a problem for dpkg. In
> order to install libfoo-dev:amd64, you'd have to remove
> libfoo-dev:i386.
Libfoo (libfoo:i386) and lib64foo (libfoo:amd64) at the same time is
practicaly a must for essential and base packages. Its an absolute
must for glibc.
Of cause this creates problems all over the places, thats what we try
to solve.
Renaming all dual installable packages for one arch is one way.
Using the ABI: <abi> field to differentiate packages and allow
packages with equal names (but different abis) is another.
Having *-dev binary-all is some sort of middle ground.
> > It would be best if all *-dev packages could be "Architecture:
> > all". That way there would be only one package that works for
> > everyone.
>
> Yes, it would. It'd even have the beneficial effect of reducing
> archive size, etc.
>
>
> But, alas, I think it is not feasible to require it for all
> packages. A "should", maybe; a "must", no.
>
>
> > Why are some *-dev packages "Architecture: <arch>"?
> > ---------------------------------------------------
> >
> > 1. static libraries
> >
> > Most sources and people don't need the static libraries. The static
> > libraries could be split into -static packages and sources that do
> > need them can depend specifically on them.
>
> I disagree strongly. Many people do need static libraries. Currently,
> it is a "must" in policy for -dev packages with libraries to provide
> them.
I'm not saying they should disapear. They should only be moved into a
seperate arch: <any> packages on which the -dev arch: all package can
depend on (if the static lib is so important).
> I object strongly to going from "must" to "must not" in a single
> release. That is contrary to our normal policy procedure of gradual
> change to allow people to adjust. I mean, it took us how many years to
> move from /usr/doc to /usr/share/doc?
For multiarch -dev packages to work there has to be a split one way or
the other:
1. make -dev arch: all and move any architecure dependend files into
another package.
2. move any architecture independent files into a -common package.
Point 2 means changing a lot of existing Build-Depends lines. Doesn't
realy change the amount of new packages or the work to get header
files consistent for multiarch.
> > 2. different header files per architecture
> >
> > The differences in the headers can be merged by using preprocessor
> > conditionals.
>
> In C[++], yes. In assembly, not sure. In many other languages,
> no. Though, thankfully, this does not affect many packages. However,
> when it does, merging through preprocessor conditionals (if such are
> even available) is no trivial undertaking, and I don't think its
> something we can reasonably require of packagers.
Worst case you ship different directories or the package gets excluded
from multiarch -dev support. Its probably acceptable for non
build-essential packages to conflict in such cases but it shouldn't be
the rule.
> > 3. support binaries in the -dev package
> >
> > I'm thinking about gtk-config, sdl-config, kde-config, ...
> > Are all of those scripts or are there some compiled programs in hte
> > mix?
>
> Compiled programs aplenty. Quick one that comes to mind is
> dpkg-dev. libc has a few as well.
dpkg-dev:amd64 works to build i386 and amd64 packages and the right
architecture can be pulled in by build-essential. It could be split
but its not a neccessity here.
> Even the scripts are architecture-dependent. Consider:
>
> anthony@bohr:anthony$ gtk-config --libs gtk
> -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib
> -ldl -lXi -lXext -lX11 -lm
>
> anthony@bohr:anthony$ gtk-config --cflags gtk
> -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
That has to be patched for multiarch to check the target cpu for what
arch it is actually going to compile. Depending on that the result of
the script has to change to have /lib/ or /lib64/.
As it is now, for non multiarch, where is there a bit of architecture
dependend information in there?
> > I suggest splitting any binary programms (if there are any) out into a
> > -helper package and have the -dev depend on them.
>
> How does this help? So instead of having the problem with libx-dev
> being both i386 and amd64, you have the problem with libx-helper being
> i386 and amd64. I don't see how that is any different, other than
> being one more package to make dselect and aptitude just a tad bit
> less usable.
The existing sources depend on the one libx-dev package, which in turn
pulls in the required set of libx-helper packages relevant for the
architecture:
Depends: libx-helper [i386, m68k, alpha, ia64, mips, sparc, powerpc, s390x], lib64x-helper [amd64, mips64, sparc64, s390x, ppc64]
On non-biarch systems you get libx-helper, on multiarch systems you
get libx-helper and lib64x-helper and on pure amd64, mips64, sparc64,
s390x, ppc64 systems you only get lib64x-helper.
> > Having "Architecture: all" *-dev packages would simplify the work for
> > multiarch support greatly so I hope noone comes up with a stronger
> > reason against it as the ones above.
>
> I have a few more:
>
> -dev packages include a symlink from lib.so to lib.so.SONAME. I don't
> know of any guarantee that the soname is architecture-independent. I
> would not be surprised to see cases where it isn't.
>
> Actually, this is a very large problem: How is an
> architecture-independent package supposed to provide a symlink from
> lib.so to lib.so.SONAME when the location of lib.so and lib.so.SONAME
> vary between architectures? (/lib, /lib64, another for MIPS, etc.)
Postint script. Depending on the subarchs for the host one, two or
three links are set.
> -dev packages should include documentation. That would be yet another
> package, -doc.
You have arch dependent docs?
> You've essentially proposed splitting -dev packages into:
> -static Static libraries
> -helper Helper binaries
> -doc (mine) documentation
> -dev header files, .so link
>
> So, from one package, to at least two (almost everyone needs a -doc
> splitoff). Up to four. So that means we'd be introducing at least
If you have -static, -helper, -doc and all are arch dependend noone is
stopping you from putting them all into one deb. The names are just
examples.
> egrep 'Package: .*-dev$' /var/lib/dpkg/available | wc -l
> 1118
>
> 1118 new packages. A reasonable guess would, I think[1], be around two
> new packages per dev package, I think, so ~2200 new packages.
One is enough to make it work. And one (libfoo-common) is what would
be required for libfoo-dev and lib64foo-dev to work too. Nothing
gained, nothing lost. The lib64foo-dev way is actually more package
names to deal with for dselect/aptitude.
> Just what dselect and aptitude need. 20% more packages to make it even
> harder for users to look through the lists.
There also seem to be ~1300 packages that have files in some /lib/
dir. All those need to be changed to /lib64/ for amd64. That doesn't
create 1300 new packages for amd64 but renames them. But then dselect
and aptitud have to combine i386 and amd64 packages into one list.
Hey, now instead of 13K packages you have 26K packages with ~16K
having uniq names.
I don't think 13K or 26K or 1M Packages makes a difference
anymore. A list of all packages is just unusable anyway. Think of
something better.
MfG
Goswin
Reply to: