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

Re: [multiarch] Proposal for *-dev packages

Thomas Viehmann <tv@beamnet.de> writes:

> Goswin von Brederlow wrote:
> > "Thomas Viehmann" <tv@beamnet.de> writes:
> > 
> > 
> >>Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) 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
> >>forever.
> > 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.
> Cheers
> T.

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.


Reply to: