Re: [multiarch] Proposal for *-dev packages
Thomas Viehmann <email@example.com> writes:
> Goswin von Brederlow wrote:
> > "Thomas Viehmann" <firstname.lastname@example.org> writes:
> >>Goswin von Brederlow (email@example.com) wrote:
> >>>... allowing "Abi: ..." and having
> >>>multiple packages with the same name installed aparently isn't liked
> >>>at all.
> >>It's not likely for sarge, but if you get it working, I'd doubt that it'd be barred
> > Never was ment for sarge. No way.
> Oh. Sorry. I've just seen some todo list where one item was "this little
> thing for sage...".
Yes, keeping the "Architecture: ...." field in the status field of
dpkg. Thats removing 2 lines in one file and changing a third line in
another. Patch is in BTS now. Its just removing the lines currently
deleting the field.
> > The -dev package would install _both_ architectures arch dependend
> > packages for multiarch and just one for non-multiarch. That way
> > multiarch has some bloat (just on the users harddisk) but will allways
> > have the right version.
> > And people can still do non multiarch amd64.
> Ah. Now I'm getting closer to see how this should work. I just don't
> know how you'd get packages to require both arch dependend stuff without
> a lot of exceptions.
> >>>And Conflict means that you can't have a user wanting 32bit programms
> >>>and one wanting 64bit programms on the same system.
> > Wanting to compile, sorry.
> Ah. I'm not quite sure why this should be a feature common enough for
> not being solved by 32 bit chroots, but if you say that this is
> required, I'm almost convinced.
A chroot means you need two compleet toolchains you have to store and
maintain. Two make, two automake, two autoconf, two libtool, ...
And you need a whole bunch of setuid programs that put people into the
right chroot depending on the arguments.
./configure TARGET=i386 -> run configure in the chroot
make -> run in chroot since configure did
./configure HOST=i386 TARGET=amd64 -> build in the chroot but for
outside the chroot
It just gets real messy.
> > The "fooSOVER-dev provides/conflicts foo-dev" doesn't help getting the
> > right -dev package for the target arch the user chooses to be
> > available or even prevent i386 -dev packages from falsely providing
> > stuff for amd64 compiles (if on 64bit developement is supported for amd64).
> Ah. Sorry. I falsely understood that the -dev packages should always be
> 64 bit...
> I'd still think that a better approach would eventually be accepted, but
> thanks for taking the time to explain the issue.
If someone comes up with one. Sofar its just going around in circles
raising more and more problems with each solution so far.
Best one is still the <pkg>:<arch> changes to dpkg.