[gentoo-dev] Random items I'd like to discuss

[gentoo-dev] Random items I'd like to discuss

[Luca Barbato]

Some items I have in wishlist

- LRDEPEND link runtime dep (I need to link against that in order to run)
- BDEPEND build dep (I need those tools in order to build)

- arch/ctarget support in deps (same way you have use deps)

- explicit ctarget support in the package manager emerge --cross=target
something.

- tools to explicitly manipulate sets

long time ideas:

- support cross, multiarch, multilib in a saner and seamless way

please comment =)

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Random items I'd like to discuss

[Ciaran McCreesh]

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

On Sat, 29 Dec 2007 22:12:11 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Some items I have in wishlist
> 
> - LRDEPEND link runtime dep (I need to link against that in order to
> run)
> - BDEPEND build dep (I need those tools in order to build)
> 
> - arch/ctarget support in deps (same way you have use deps)

Have a look at the labels bug (201499).

> - explicit ctarget support in the package manager emerge
> --cross=target something.

Would need support from every ebuild, which in turn would need support
from every upstream.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Random items I'd like to discuss

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 29 Dec 2007 22:12:11 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Some items I have in wishlist
>>
>> - LRDEPEND link runtime dep (I need to link against that in order to
>> run)
>> - BDEPEND build dep (I need those tools in order to build)
>>
>> - arch/ctarget support in deps (same way you have use deps)
> 
> Have a look at the labels bug (201499).

Similar idea, but I don't like the labels that much,

having separate vars can make backward compatibility easy

DEPEND="$BDEPEND $LRDEPEND"
RDEPEND="$LRDEPEND $stuff"

> 
>> - explicit ctarget support in the package manager emerge
>> --cross=target something.
> 
> Would need support from every ebuild, which in turn would need support
> from every upstream.

every autostuff ebuild should and that's a start.

you can restrict the tree to a specific branch supporting this feature
and extend it little by little.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Random items I'd like to discuss

[Ciaran McCreesh]

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

On Sat, 29 Dec 2007 22:47:50 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> > Have a look at the labels bug (201499).
> 
> Similar idea, but I don't like the labels that much,
> 
> having separate vars can make backward compatibility easy

You can't sensibly have backwards compatibility across new deps if all
the requested options are implemented anyway -- there's no exact
mapping between the current three vars and all the new ones. New deps
has to be an EAPI change, and it has to be an ebuild change.

And the other problem -- we'd be talking hundreds of variables.
Multiply number of dep types (build, run, install, compile against,
post, probably more) by number of requirement levels (required,
suggested, recommended) by number of ABI combinations by number of
system combinations by whatever else ends up being useful.

> >> - explicit ctarget support in the package manager emerge
> >> --cross=target something.
> > 
> > Would need support from every ebuild, which in turn would need
> > support from every upstream.
> 
> every autostuff ebuild should and that's a start.

Except that autotools doesn't have any sane way of handling chost /
cbuild / ctarget for non-trivial packages. If you want to do something
simple like generate a file using a program you make at compile time,
you're forced to resort to nicking insane hackery from the gcc build
system -- or you can do what most people do and just break non-native
compiles. Using autotools does not mean supporting chost / cbuild /
ctarget properly...

> you can restrict the tree to a specific branch supporting this feature
> and extend it little by little.

Tree branching will very quickly become unmanageable. Users will be
forced to choose a branch, but useful features will be spread across
different branches.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Random items I'd like to discuss

[Luca Barbato]

Ciaran McCreesh wrote:
> You can't sensibly have backwards compatibility across new deps if all
> the requested options are implemented anyway -- there's no exact
> mapping between the current three vars and all the new ones. New deps
> has to be an EAPI change, and it has to be an ebuild change.

for the ones I pointed it is ^^;

> And the other problem -- we'd be talking hundreds of variables.

hundreds -> bad, no matter what.

> Multiply number of dep types (build, run, install, compile against,
> post, probably more) by number of requirement levels (required,
> suggested, recommended) by number of ABI combinations by number of
> system combinations by whatever else ends up being useful.

I'm against suggested and recommended. I don't like it in debian and I
won't like it in gentoo. the rest shouldn't interest an ebuild by itself
but should be handled by the package manager.

>> every autostuff ebuild should and that's a start.
> 
> Except that autotools doesn't have any sane way of handling chost /
> cbuild / ctarget for non-trivial packages. If you want to do something
> simple like generate a file using a program you make at compile time,
> you're forced to resort to nicking insane hackery from the gcc build
> system -- or you can do what most people do and just break non-native
> compiles. Using autotools does not mean supporting chost / cbuild /
> ctarget properly...

bad users of tools are always present, by itself autotools gives support
and usually works out of box.

> Tree branching will very quickly become unmanageable. Users will be
> forced to choose a branch, but useful features will be spread across
> different branches.

Only if you don't manage it correctly.

I know what I'm doing on linux and it is _quite_ branched.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Random items I'd like to discuss

[Ciaran McCreesh]

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

On Sun, 30 Dec 2007 08:38:10 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> > Multiply number of dep types (build, run, install, compile against,
> > post, probably more) by number of requirement levels (required,
> > suggested, recommended) by number of ABI combinations by number of
> > system combinations by whatever else ends up being useful.
> 
> I'm against suggested and recommended. I don't like it in debian and I
> won't like it in gentoo. the rest shouldn't interest an ebuild by
> itself but should be handled by the package manager.

The package manager can't. It needs to be told -- there's no way to
guess up front (or, indeed, after the fact) what dependencies really
are.

> bad users of tools are always present, by itself autotools gives
> support and usually works out of box.

No, autotools doesn't give support. It doesn't, for example, have any
way of generating source files using a program that's part of the
package that requires a library that's part of the package. The sad
fact is, no matter how you use autotools in non-trivial cases you'll
end up breaking *something*, and cross compiling is the least visible
thing to break.

> > Tree branching will very quickly become unmanageable. Users will be
> > forced to choose a branch, but useful features will be spread across
> > different branches.
> 
> Only if you don't manage it correctly.
> 
> I know what I'm doing on linux and it is _quite_ branched.

That's because things get merged in quickly...

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Random items I'd like to discuss

[Steve Long]

Luca Barbato wrote:

> Some items I have in wishlist
> 
> - LRDEPEND link runtime dep (I need to link against that in order to run)

I heartily concur with a link dependency, since it's such a fundamental
relationship between packages: if A links to B we need to recompile A when
the ABI for B changes. How useful is the distinction between runtime vs
buildtime in that respect? (I can't see the point of linking to something
if it's never used at runtime.)

> - BDEPEND build dep (I need those tools in order to build)
>
Agreed. I'd hope LDEPEND and BDEPEND could cover all current DEPEND uses.
Either you depend on something to be installed as you link to its headers
and use it at runtime, or you need the tool to build, eg make. (RDEPENDs
with no linkage, and hence no requirement to be installed at build-time,
and PDEPENDs to break circular chains are the ones I know about.) But I
don't know how that interacts with || DEPENDs.

wrt SUGGEST et al, I don't see why those can't be kept separately in
metadata.xml, if labelling isn't implemented, since they're only of use for
package selection, not depgraph resolution (as I understand it).

> - arch/ctarget support in deps (same way you have use deps)
>
Interesting idea.
 
> - explicit ctarget support in the package manager emerge --cross=target
> something.
>
Definitely, at least as much as we can do with the standard variables and
GNU make. So not everything will cross-compile, that's to be expected. It
would be cool to tie that into the tinderbox stuff that solar and
bonsaikitten have done, so that testing could be automated.

> - tools to explicitly manipulate sets
>
I must be missing something with these: they just seem like lists of
packages (which you might want updated together, or compiled with the same
set of flags etc.) That kind of stuff is more to do with scripting afaict,
than the core package manager. (eg using predefined files for any and all
configuration before compiling, and then resetting once the set is built.
Recovery issues aren't so bad if the user knows the machine has crashed and
runs the program to reset stuff before anything else is emerged.)

> long time ideas:
> 
> - support cross, multiarch, multilib in a saner and seamless way
>
Yeah, even if it means building everything in a chroot, for development libs
at least. http://tldp.org/HOWTO/Multi-Distro-Dev/use.html (old) reminds me
of this; I found it the other day and it looked a lot like stuff we do in
Gentoo chroots.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Random items I'd like to discuss

[Luca Barbato]

Marius Mauch wrote:
> On Sat, 29 Dec 2007 22:12:11 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
>> - tools to explicitly manipulate sets
> 
> Elaborate.
> 
> Marius

add/remove/move packages to a set

on merge command you can define additional sets in which put the package

etc etc etc.

lu - I'll elaborate more tomorrow...

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list