[gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[Luca Barbato]

yesterday we discussed about cross development and why the gentoo
support for it works just to a point (and then has something missing)

There are already some convoluted ideas about multiabi/multilib support
with patches being discussed and there are some handy scripts that let
you cross emerge stuff to a point (it has to be an autotooled package or
has to be cross aware, it shouldn't depend on running certain programs).

the first way aims at integrate the multiabi concept in a quite tight
way, the other just makes portage consider it a completely separated
beast and just ignore the rest.

The nicer way should be just have another dep list that shows which
rdeps should REALLY be run in order to get the package built and which
are just deps needed to run the package itself.

the simple/dumb way to treat this list is something like:

you walk the cross dep list, for each atom in the dep with a run to
build dep prepare a list to feed to the host configured package manager
and build it first, then move to the cross dep list and threat it as it
is a completely separated instance.

Sounds too simple to be complete but I think for simple stuff like doc
creation and cvs/svn/git/hg.. dep for live ebuilds should work pretty fine.

PMS overlords what's your take?

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

On Wed, 06 Jun 2007 11:24:00 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> PMS overlords what's your take?

You need to start by identifying use cases. Are you discussing handling
cross compiling, multilib, C++ / python ABIs or all of them? Then you
need to identify what packages would need to do to handle those things.
Don't even think about the package manager side until you've worked out
what ebuilds would do.

-- 
Ciaran McCreesh


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Wed, 06 Jun 2007 11:24:00 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> PMS overlords what's your take?
> 
> You need to start by identifying use cases. Are you discussing handling
> cross compiling, 

Yes
multilib,

Ok
 C++ / python ABIs

Aaaaaargh, ehm, should we really throw them in the mix? anyway let me
see if the same rules apply:

- they have to reside in a separate path if possible?

- the linker must not pick wrong ones in place of the ones you want to use.

- an application using a former abi must link depend on stuff from the
same place but MAY use stuff from another place.

- is up to the loader pick the right paths on execution

- the dep resolver should ignore packages built using the other
C++/Python abi.

The issue is more complex and I just ignored it basically because the
library abi mismatch is an error that should be rectified and not
something you want and no it isn't because I don't care about binary
only stuff right now, it's just because looks like there is already too
much meat w/out something that fits just halfway on the constraints.

 or all of them? Then you
> need to identify what packages would need to do to handle those things.

All.

> Don't even think about the package manager side until you've worked out
> what ebuilds would do.

autotooled programs more or less are already doing the right thing, non
autotools packages supporting cross development may require some
additional checks to pass the right target.

lu


-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Wednesday 06 June 2007, Luca Barbato wrote:
> yesterday we discussed about cross development and why the gentoo
> support for it works just to a point (and then has something missing)
>
> There are already some convoluted ideas about multiabi/multilib support
> with patches being discussed and there are some handy scripts that let
> you cross emerge stuff to a point (it has to be an autotooled package or
> has to be cross aware, it shouldn't depend on running certain programs).

There are various problems that need to be addressed for cross development and 
(especially) multilib/abi. One of the other ones that you didn't mention is 
some kind of subpackage support. For example when one installs 32 bit gtk+ to 
use binary firefox on an 64bit system it can share the headers and docs etc. 
with the 64 bit version. Removing either of them must however still preserve 
those files.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[Luca Barbato]

Paul de Vrieze wrote:
> There are various problems that need to be addressed for cross development and 
> (especially) multilib/abi. One of the other ones that you didn't mention is 
> some kind of subpackage support. For example when one installs 32 bit gtk+ to 
> use binary firefox on an 64bit system it can share the headers and docs etc. 
> with the 64 bit version. Removing either of them must however still preserve 
> those files.

A quick and dirty way implies that:
- only the "main" abi can install stuff /usr/
- includes live in their /usr/$arch/include/
- docs may live /usr/$arch/usr/share/doc/ or just be suppressed.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
> Paul de Vrieze wrote:
> > There are various problems that need to be addressed for cross development and 
> > (especially) multilib/abi. One of the other ones that you didn't mention is 
> > some kind of subpackage support. For example when one installs 32 bit gtk+ to 
> > use binary firefox on an 64bit system it can share the headers and docs etc. 
> > with the 64 bit version. Removing either of them must however still preserve 
> > those files.
> 
> A quick and dirty way implies that:
> - only the "main" abi can install stuff /usr/

The secondary need to be able to install into their /usr/${libdir} ..
its actually the only place where stuff from the non-main abis should be
imho.

> - includes live in their /usr/$arch/include/
> - docs may live /usr/$arch/usr/share/doc/ or just be suppressed.
> 
> lu
> 
> -- 
> 
> Luca Barbato
> 
> Gentoo/linux Gentoo/PPC
> http://dev.gentoo.org/~lu_zero
-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[Paul de Vrieze]

On Sat, 30 Jun 2007 01:12:02 Olivier Crête wrote:
> On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
> > Paul de Vrieze wrote:
> > > There are various problems that need to be addressed for cross
> > > development and (especially) multilib/abi. One of the other ones that
> > > you didn't mention is some kind of subpackage support. For example when
> > > one installs 32 bit gtk+ to use binary firefox on an 64bit system it
> > > can share the headers and docs etc. with the 64 bit version. Removing
> > > either of them must however still preserve those files.
> >
> > A quick and dirty way implies that:
> > - only the "main" abi can install stuff /usr/
>
> The secondary need to be able to install into their /usr/${libdir} ..
> its actually the only place where stuff from the non-main abis should be
> imho.

If one requires synchronized versions, there should in 99% of the cases not be 
any issue with header files and documentation. It will be equal, so can be 
shared. It might indeed be an option to require the "main" abi to be always 
present.

Paul
ps. for include headers it is rather straightforward to make forwarding 
headers with architecture dependent redirects (using the architecture 
defines) in case the headers are not arch independent.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

On Wed, 2007-04-07 at 22:11 +1000, Paul de Vrieze wrote:
> On Sat, 30 Jun 2007 01:12:02 Olivier Crête wrote:
> > On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
> > > Paul de Vrieze wrote:
> > > > There are various problems that need to be addressed for cross
> > > > development and (especially) multilib/abi. One of the other ones that
> > > > you didn't mention is some kind of subpackage support. For example when
> > > > one installs 32 bit gtk+ to use binary firefox on an 64bit system it
> > > > can share the headers and docs etc. with the 64 bit version. Removing
> > > > either of them must however still preserve those files.
> > >
> > > A quick and dirty way implies that:
> > > - only the "main" abi can install stuff /usr/
> >
> > The secondary need to be able to install into their /usr/${libdir} ..
> > its actually the only place where stuff from the non-main abis should be
> > imho.
> 
> If one requires synchronized versions, there should in 99% of the cases not be 
> any issue with header files and documentation. It will be equal, so can be 
> shared. It might indeed be an option to require the "main" abi to be always 
> present.

I really don't see how it can be made to work in a generic wait without
requiring that all sub-arches use the same version as the main arch and
without requiring that the main arch be installed (if we were a binary
distro, we could do a common package and a bunch of sub-packages, but
now we can't).

> Paul
> ps. for include headers it is rather straightforward to make forwarding 
> headers with architecture dependent redirects (using the architecture 
> defines) in case the headers are not arch independent.

In theory, headers in /usr/include should be arch independant. You if
you at glib, it installs its arch dependant header in /usr/lib

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]