Re: [multiarch] Proposal for *-dev packages
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.
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.
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 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?
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.
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.
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
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.
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.)
-dev packages should include documentation. That would be yet another
package, -doc.
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
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.
Just what dselect and aptitude need. 20% more packages to make it even
harder for users to look through the lists.
Currently adding gasoline to the fire,
Anthony
Let the flames burn brightly,
Goswin
[0] Anyone who mentions a horse gets thrown in as fuel for the
flames.
[1] Meaning I'm unwilling to do actual research into 1100 packages
to find out.
Reply to: