Re: [multiarch] Proposal for *-dev packages
On Jan 15, 2004, at 04:29, Goswin von Brederlow wrote:
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).
OK, so Build-Essential are an exception to this.
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.
Remove, not purge, I'd hope.
That's why I say it is a nice "should".
Just consider compiling a benchmark that tests 32 bit and 64 bit
support. That would be hell.
Agreed.
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).
If there was actually a good reason to separate out the static libs,
you can't depend on them. The goal was to allow a libfoo-dev to be
installed that would work for both 32-bit and 64-bit builds.
If it is impossible to have static libraries for both 32-bit and 64-bit
in libfoo-dev itself, it is no more possible for libfoo-dev to depend
on them.
Then again, why are .a files a problem? Don't the i386 ones go in
.../lib, and the amd64 ones in .../lib64?
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 doesn't involve changing Build-Depends lines, AFAICT. If both
libfoo-dev:amd64 and libfoo-dev:i386 depend on libfoo-dev-common:all
then you can still install them both at once.
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.
Then there is a good reason against a "must" in policy.
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/.
A little harder to do for the packagecfg files, as someone else pointed
out... But I suppose those will be split by /lib vs. /lib64.
As it is now, for non multiarch, where is there a bit of architecture
dependend information in there?
None in the GTK one, AFAICT. cflags could be, though.
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.
What does that gain? Surely, most every package is going to be built
for i386 and amd64 separately? And you're proposing changing,
apparently, ~1000 packages.
How about instead we deal with the architecture-independent parts by
splitting that off if we absolutely have to (I have an idea how we
could avoid this...)? Then we interpret:
Build-Depends: foo
as
Build-Depends: foo:$ARCH
where $ARCH is the architecture we're building for. Packages that build
for both architectures at the same time (glibc, what else) could:
Build-Depends: foo:amd64 [amd64], foo:i386 [amd64], foo [!amd64]
This has the advantage of working properly even if foo:amd64 and
foo:i386 conflict with each other. We can finish the port and then work
on optimizing things by removing lib conflicts.
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.
Then the .so files don't get in dpkg's file database, which certainly
isn't a benefit.
-dev packages should include documentation. That would be yet another
package, -doc.
You have arch dependent docs?
ummm... err... oops... good point.
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.
OK, so we're only talking 1100 new packages. Certainly better than
2200...
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.
FYI, I thin renaming the packages is not a good idea.
Reply to: