Re: [multiarch] Proposal for *-dev packages
Anthony DeRobertis <asd@suespammers.org> writes:
> On Jan 15, 2004, at 04:29, Goswin von Brederlow wrote:
>
> >>> 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?
They are no problem due to /lib and /lib64. Problem is just you need
to specifically depend on both of them. Limiting the number of
packages needing this change is the point. Its not like debian is
building static kde applications. :)
> > 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.
Only if the first idea of allowing multiple packages with the same
name is accepted, which had objections.
Otherwise its libfoo-dev:i386 and lib64foo-dev:amd64, which means
changing the Build-Depends.
The idea for the Arch:all -dev packages is that since we have to
touch, patch and split the -dev packages anyway lets split out the
binary stuff and make the -dev package the arch: all.
I think its the same amount of work to split it either way but arch:
all -dev saves changing the Build-Depends.
> > 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.
Yes, for non build-essential packages. Certainly a must for everything
is out of the question for sarge+1.
I think that header files that are generated for each arch at compile
time are a pretty broken design. Just look at linux-kernel-headers
bugs for some problems.
> >> 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.
pkg-config has to look at /usr/lib or /usr/lib64 depending on the
target host. If pkg-config itself is not adaptable a little wraper
script that calls /usr/lib/pkg-config/pkg-config or
/usr/lib64/pkg-config/pkg-config depending on the target is simple
enough.
> > 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.
CFLGAS ar stored in the dpkg subarchtable and should be used from
there. The subarch table includes special cpu flags for different
subarchs pkg-config is not supposed to know or care about too.
But thats a different storry.
> > 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.
Every library package has to be changed for 64bit multiarchs
anyway. Only packages that have to be changed or not depending on the
design are binaries.
> 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.
That mean I need a make:amd64 before anything can be build. But a make
i386 is perfectly fine. Ok, no problem with make. But there are a lot
of tools needed to compile packages and anything thats binary can be
used as 32 bit version.
Requiring a 64bit toolchain might be ok for amd64, but mips, sparc,
ppc64, s390x certainly don't need a complete 64 bit toolchain, which
would be bigger and slower.
> >> 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.
So do I but others seem not to agree. The "one package one name"
'rule' stands in the way of that.
MfG
Goswin
Reply to: