[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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

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 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,

Let the flames burn brightly,
[0] Anyone who mentions a horse gets thrown in as fuel for the
[1] Meaning I'm unwilling to do actual research into 1100 packages
    to find out.

Reply to: