[gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

Please consider a PROPERTIES=set value that allows an ebuild to
indicate that it should behave like a package set when selected on
the command line. This is behavior is somewhat difficult to describe
in words but the following example should be sufficient to convey
the general idea. Consider a case where all of the kde-base/*-meta
packages exhibit the "set" property, and these packages and their
dependencies are currently installed. In such a case, the default
behavior for a command such as `emerge kde-base/kde-meta` should be
to reinstall the the selected kde-base/kde-meta ebuild and the set
of packages which includes it's direct dependencies and it's
recursive "set" dependencies. So, assuming that all USE flags are
enabled for the selected kde-base/kde-meta ebuild, it would
reinstall the direct dependencies of kdeartwork-meta, kdebase-meta,
kdeedu-meta, kdegames-meta, kdegraphics-meta, kdemultimedia-meta,
kdenetwork-meta, kdetoys-meta, kdeutils-meta, and
kdeaccessibility-meta ebuilds. Similarly, the default behavior for a
command such as `emerge --unmerge kde-base/kde-meta` would be to
uninstall the same set of packages.

The advantage of using the PROPERTIES=set approach, rather than some
alternative approach, is that the PROPERTIES=set approach fits
nicely into the existing framework, similar to the way that
"virtual" ebuilds [1] fit into the existing framework. For example,
/etc/portage/package.use can be used to control the USE flags of
these "set" ebuilds in the same way that it is currently used to
control any other package. Also, tools that are designed to work
with existing ebuilds will continue to work just as well with "set"
ebuilds.

Similar to the proposed "virtual" property [2], the "set" property
will indicate that dependency calculations should consider the
ebuild to have zero installation cost. Other than this, an ebuild
which exhibits the "set" property should behave just like any other
ebuild. It should be installed and uninstalled just like any other
ebuild, including execution of all the normal ebuild phase functions
that would be executed for any other ebuild that does not exhibit
the "set" property.

Does this seem like a good approach? Are there any suggestions for
improvements or alternative approaches?

[1] http://www.gentoo.org/proj/en/glep/glep-0037.html
[2]
http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjezf0ACgkQ/ejvha5XGaN78wCg3RHVdox0VaFq+241zVWRkNTH
6H8AoNNMw/I1bWPzM13yN2PMDg6+MTmD
=dxEx
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Marius Mauch]

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

On Sat, 27 Sep 2008 17:21:18 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi everyone,
> 
> Please consider a PROPERTIES=set value that allows an ebuild to
> indicate that it should behave like a package set when selected on
> the command line. This is behavior is somewhat difficult to describe
> in words but the following example should be sufficient to convey
> the general idea. Consider a case where all of the kde-base/*-meta
> packages exhibit the "set" property, and these packages and their
> dependencies are currently installed. In such a case, the default
> behavior for a command such as `emerge kde-base/kde-meta` should be
> to reinstall the the selected kde-base/kde-meta ebuild and the set
> of packages which includes it's direct dependencies and it's
> recursive "set" dependencies. So, assuming that all USE flags are
> enabled for the selected kde-base/kde-meta ebuild, it would
> reinstall the direct dependencies of kdeartwork-meta, kdebase-meta,
> kdeedu-meta, kdegames-meta, kdegraphics-meta, kdemultimedia-meta,
> kdenetwork-meta, kdetoys-meta, kdeutils-meta, and
> kdeaccessibility-meta ebuilds. Similarly, the default behavior for a
> command such as `emerge --unmerge kde-base/kde-meta` would be to
> uninstall the same set of packages.

I'm not convinced that this is a good idea if some packages suddenly
behave _vastly_ different than others (from a users POV) without any
clear indication (a -meta somewhere in the name IMO doesn't count).

Maybe we can just create a PackageSet class that wraps a package though
to get the same behavior while keeping the two behaviors separated by
syntax.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marius Mauch wrote:
> On Sat, 27 Sep 2008 17:21:18 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi everyone,
>>
>> Please consider a PROPERTIES=set value that allows an ebuild to
>> indicate that it should behave like a package set when selected on
>> the command line. This is behavior is somewhat difficult to describe
>> in words but the following example should be sufficient to convey
>> the general idea. Consider a case where all of the kde-base/*-meta
>> packages exhibit the "set" property, and these packages and their
>> dependencies are currently installed. In such a case, the default
>> behavior for a command such as `emerge kde-base/kde-meta` should be
>> to reinstall the the selected kde-base/kde-meta ebuild and the set
>> of packages which includes it's direct dependencies and it's
>> recursive "set" dependencies. So, assuming that all USE flags are
>> enabled for the selected kde-base/kde-meta ebuild, it would
>> reinstall the direct dependencies of kdeartwork-meta, kdebase-meta,
>> kdeedu-meta, kdegames-meta, kdegraphics-meta, kdemultimedia-meta,
>> kdenetwork-meta, kdetoys-meta, kdeutils-meta, and
>> kdeaccessibility-meta ebuilds. Similarly, the default behavior for a
>> command such as `emerge --unmerge kde-base/kde-meta` would be to
>> uninstall the same set of packages.
> 
> I'm not convinced that this is a good idea if some packages suddenly
> behave _vastly_ different than others (from a users POV) without any
> clear indication (a -meta somewhere in the name IMO doesn't count).
> 
> Maybe we can just create a PackageSet class that wraps a package though
> to get the same behavior while keeping the two behaviors separated by
> syntax.

Some some sort of mapping of packages into sets space does seem
better than changing the behavior of these packages other cases.
However, PROPERTIES=set will still be useful for governing
recursion, since recursion into dependencies is probably not desired
for non-meta packages in the same sense that it might be desired for
meta-packages.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjfwg4ACgkQ/ejvha5XGaMkYACdF/uvOatcWaw1DsQkY/nBZ6RW
N4YAn2VFsZztPLzHO6V6T9eQER4b2tO9
=z2qG
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ciaran McCreesh]

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

On Sun, 28 Sep 2008 10:42:39 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> Some some sort of mapping of packages into sets space does seem
> better than changing the behavior of these packages other cases.
> However, PROPERTIES=set will still be useful for governing
> recursion, since recursion into dependencies is probably not desired
> for non-meta packages in the same sense that it might be desired for
> meta-packages.

So you're saying that if a package depends upon all of foo, and a user
wants to do a deep or empty tree reinstall, all of foo shouldn't get
upgraded or reinstalled?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 10:42:39 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> Some some sort of mapping of packages into sets space does seem
>> better than changing the behavior of these packages other cases.
>> However, PROPERTIES=set will still be useful for governing
>> recursion, since recursion into dependencies is probably not desired
>> for non-meta packages in the same sense that it might be desired for
>> meta-packages.
> 
> So you're saying that if a package depends upon all of foo, and a user
> wants to do a deep or empty tree reinstall, all of foo shouldn't get
> upgraded or reinstalled?
> 

No, that sort of behavior should be governed by various package
manager options. The primary purpose of PROPERTIES=set is only
differentiate packages that behave as package sets from those that
do not.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjf7JsACgkQ/ejvha5XGaMF1gCfb599X9JM/8rvoOx0mLc5aMMm
PN0AoLOOOIewiZSey0O1/jA+lF2F22FV
=2xMK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ciaran McCreesh]

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

On Sat, 27 Sep 2008 17:21:18 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> Does this seem like a good approach? Are there any suggestions for
> improvements or alternative approaches?

Strikes me as a good way of causing extreme confusion for users...

Consider sets in package.use, for example. Any specified flags should
apply to the entire set. But what about set-property packages?

Sets and packages aren't the same thing, and shouldn't be treated as if
they are.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sat, 27 Sep 2008 17:21:18 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> Does this seem like a good approach? Are there any suggestions for
>> improvements or alternative approaches?
> 
> Strikes me as a good way of causing extreme confusion for users...

Perhaps it's not so confusing if the packages continue to behave
normally in the usual cases, but they are mapped into set space as
suggested earlier [1].

> Consider sets in package.use, for example. Any specified flags should
> apply to the entire set. But what about set-property packages?

In order to fit into the ebuild framework, the specified flags would
only apply to direct dependency atoms. Atoms pulled in by recursion
into other set-property packages would have the flags applied from
those respective set-property packages.

> Sets and packages aren't the same thing, and shouldn't be treated as if
> they are.

Packages and virtuals aren't the same thing either, but glep 37
virtuals fit quite well into the existing ebuild framework. It seems
to me that set-property packages will also fit nicely into the
existing ebuild framework.

[1]
http://archives.gentoo.org/gentoo-dev/msg_d858a9a516fe3d1996c3809fba56f1db.xml
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjf7rcACgkQ/ejvha5XGaNlzQCfYrvTNDVTqqZjXgc7rUkfjT6J
8PMAmgLkC4dcprNL6GnuHzWUzM9zabxk
=91yT
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ciaran McCreesh]

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

On Sun, 28 Sep 2008 13:53:12 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> >> Does this seem like a good approach? Are there any suggestions for
> >> improvements or alternative approaches?
> > 
> > Strikes me as a good way of causing extreme confusion for users...
> 
> Perhaps it's not so confusing if the packages continue to behave
> normally in the usual cases, but they are mapped into set space as
> suggested earlier [1].

Then why not just make the things sets? Come up with a standard way of
distributing sets as part of a repository, and let future EAPIs include
deps upon sets.

> > Consider sets in package.use, for example. Any specified flags
> > should apply to the entire set. But what about set-property
> > packages?
> 
> In order to fit into the ebuild framework, the specified flags would
> only apply to direct dependency atoms. Atoms pulled in by recursion
> into other set-property packages would have the flags applied from
> those respective set-property packages.

Right, so you'd get the bizarre case that, given:

cat/foo one
cat/bar two
cat/baz three

The one flag applies onto to cat/foo, the three flag applies only to
cat/baz but the two flag applies to cat/monkey and cat/hamster.

Sets need to *look* different...

> > Sets and packages aren't the same thing, and shouldn't be treated
> > as if they are.
> 
> Packages and virtuals aren't the same thing either, but glep 37
> virtuals fit quite well into the existing ebuild framework. It seems
> to me that set-property packages will also fit nicely into the
> existing ebuild framework.

GLEP 37 effectively abolishes virtuals. It doesn't try to overload new
behaviour onto packages.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 13:53:12 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>>>> Does this seem like a good approach? Are there any suggestions for
>>>> improvements or alternative approaches?
>>> Strikes me as a good way of causing extreme confusion for users...
>> Perhaps it's not so confusing if the packages continue to behave
>> normally in the usual cases, but they are mapped into set space as
>> suggested earlier [1].
> 
> Then why not just make the things sets? Come up with a standard way of
> distributing sets as part of a repository, and let future EAPIs include
> deps upon sets.

We can even do both. We could come up with a standard way to
distribute sets and make PROPERTIES=set be one of the possible
formats used for set distribution.

>>> Consider sets in package.use, for example. Any specified flags
>>> should apply to the entire set. But what about set-property
>>> packages?
>> In order to fit into the ebuild framework, the specified flags would
>> only apply to direct dependency atoms. Atoms pulled in by recursion
>> into other set-property packages would have the flags applied from
>> those respective set-property packages.
> 
> Right, so you'd get the bizarre case that, given:
> 
> cat/foo one
> cat/bar two
> cat/baz three
> 
> The one flag applies onto to cat/foo, the three flag applies only to
> cat/baz but the two flag applies to cat/monkey and cat/hamster.
> 
> Sets need to *look* different...

It seems like more of a feature to me, rather than a problem. The
idea is that sets can nest other sets, and at the same time nested
sets can have different USE conditional settings than the sets that
nest them.

>>> Sets and packages aren't the same thing, and shouldn't be treated
>>> as if they are.
>> Packages and virtuals aren't the same thing either, but glep 37
>> virtuals fit quite well into the existing ebuild framework. It seems
>> to me that set-property packages will also fit nicely into the
>> existing ebuild framework.
> 
> GLEP 37 effectively abolishes virtuals. It doesn't try to overload new
> behaviour onto packages.

Well, PROPERTIES=set doesn't necessarily need overload new behavior
onto packages any more that virtual ebuilds do. If set-property
ebuilds are mapped into set space then the overloaded behavior will
come from them being referenced as sets, which won't overload their
ebuild behavior since they can simply behave like existing
meta-packages already do.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjgAR0ACgkQ/ejvha5XGaNmDQCfSO4J2fs2aaLHXZ9/MOABy6E1
654AnRDLDgJzWyyzzHX3ef5zIufePX62
=0GO8
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ciaran McCreesh]

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

On Sun, 28 Sep 2008 15:11:42 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> > GLEP 37 effectively abolishes virtuals. It doesn't try to overload
> > new behaviour onto packages.
> 
> Well, PROPERTIES=set doesn't necessarily need overload new behavior
> onto packages any more that virtual ebuilds do. If set-property
> ebuilds are mapped into set space then the overloaded behavior will
> come from them being referenced as sets, which won't overload their
> ebuild behavior since they can simply behave like existing
> meta-packages already do.

Ok, so say we have cat/foo-1:

    PROPERTIES=""
    DEPEND="cat/one cat/two cat/three"
    RDEPEND="cat/two cat/four"

and cat/foo-2:

    PROPERTIES="set"
    DEPEND="cat/one cat/two cat/three"
    RDEPEND="cat/two cat/four"

Then what does this do in package.use?

    cat/foo monkey

What does this do in package.mask?

    cat/foo

What about this?

    >=cat/foo-2

What about this?

    <cat/foo-2

What does this do?

    emerge -uDpv cat/foo

What about this?

    emerge -uDpv \>=cat/foo-2

What about this?

    emerge -uDpv \<cat/foo-2

Now let's introduce cat/bar-1:

    DEPEND="cat/foo"

and cat/bar-2:

    DEPEND="=cat/foo-1"

What does this do?

    emerge -e cat/bar

What about:

    emerge -e =cat/bar-1

And how is this anything other than highly weird?

Here's an alternate proposal: Repositories can ship sets via files in
sets/*.conf. The format is as described in [1]. In configuration files,
operations applied to a set are applied to anything matching any spec
listed in that set (or any set that set contains, and so on). On the
command line, sets and non-sets cannot be mixed, and multiple sets
cannot be specified.

[1]: http://paludis.pioto.org/configuration/sets.html

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 15:11:42 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>>> GLEP 37 effectively abolishes virtuals. It doesn't try to overload
>>> new behaviour onto packages.
>> Well, PROPERTIES=set doesn't necessarily need overload new behavior
>> onto packages any more that virtual ebuilds do. If set-property
>> ebuilds are mapped into set space then the overloaded behavior will
>> come from them being referenced as sets, which won't overload their
>> ebuild behavior since they can simply behave like existing
>> meta-packages already do.
> 
> Ok, so say we have cat/foo-1:
> 
>     PROPERTIES=""
>     DEPEND="cat/one cat/two cat/three"
>     RDEPEND="cat/two cat/four"
> 
> and cat/foo-2:
> 
>     PROPERTIES="set"
>     DEPEND="cat/one cat/two cat/three"
>     RDEPEND="cat/two cat/four"
> 
> Then what does this do in package.use?
> 
>     cat/foo monkey
> 
> What does this do in package.mask?
> 
>     cat/foo
> 
> What about this?
> 
>     >=cat/foo-2
> 
> What about this?
> 
>     <cat/foo-2
> 
> What does this do?
> 
>     emerge -uDpv cat/foo
> 
> What about this?
> 
>     emerge -uDpv \>=cat/foo-2
> 
> What about this?
> 
>     emerge -uDpv \<cat/foo-2
> 
> Now let's introduce cat/bar-1:
> 
>     DEPEND="cat/foo"
> 
> and cat/bar-2:
> 
>     DEPEND="=cat/foo-1"
> 
> What does this do?
> 
>     emerge -e cat/bar
> 
> What about:
> 
>     emerge -e =cat/bar-1
> 
> And how is this anything other than highly weird?

As I've tried to explain, the an ebuild which exhibits
PROPERTIES=set doesn't necessarily have to behave any differently
than a meta-package currently does. What we would do is create a
configuration that maps the set-property ebuild into set space. For
example, `emerge kde-meta` would behave as as normal meta-package
currently does, and `emerge @kde-meta` would reference the same
package as a set and could thereby trigger different behavior which
is appropriate for a set.

> Here's an alternate proposal: Repositories can ship sets via files in
> sets/*.conf. The format is as described in [1]. In configuration files,
> operations applied to a set are applied to anything matching any spec
> listed in that set (or any set that set contains, and so on). On the
> command line, sets and non-sets cannot be mixed, and multiple sets
> cannot be specified.
> 
> [1]: http://paludis.pioto.org/configuration/sets.html
> 

Perhaps can use something like you've got there in addition to the
PROPERTIES=set approach.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjgC5oACgkQ/ejvha5XGaP0XwCdGbv7hIybD0k+GwRDTmyum3yY
kusAoIs4Imz4tNtb18srdk3VzJM/+ZHJ
=h5ii
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ciaran McCreesh]

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

On Sun, 28 Sep 2008 15:56:27 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> As I've tried to explain, the an ebuild which exhibits
> PROPERTIES=set doesn't necessarily have to behave any differently
> than a meta-package currently does. What we would do is create a
> configuration that maps the set-property ebuild into set space. For
> example, `emerge kde-meta` would behave as as normal meta-package
> currently does, and `emerge @kde-meta` would reference the same
> package as a set and could thereby trigger different behavior which
> is appropriate for a set.

...and what would that behaviour be? What does a PDEPEND mean for a
set?

> > Here's an alternate proposal: Repositories can ship sets via files
> > in sets/*.conf. The format is as described in [1]. In configuration
> > files, operations applied to a set are applied to anything matching
> > any spec listed in that set (or any set that set contains, and so
> > on). On the command line, sets and non-sets cannot be mixed, and
> > multiple sets cannot be specified.
> > 
> > [1]: http://paludis.pioto.org/configuration/sets.html
> > 
> 
> Perhaps can use something like you've got there in addition to the
> PROPERTIES=set approach.

Why the need for multiple solutions at all? PROPERTIES=set is too weird
and involves too much nonsensical behaviour to be useful.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 28 Sep 2008 15:56:27 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> As I've tried to explain, the an ebuild which exhibits
>> PROPERTIES=set doesn't necessarily have to behave any differently
>> than a meta-package currently does. What we would do is create a
>> configuration that maps the set-property ebuild into set space. For
>> example, `emerge kde-meta` would behave as as normal meta-package
>> currently does, and `emerge @kde-meta` would reference the same
>> package as a set and could thereby trigger different behavior which
>> is appropriate for a set.
> 
> ...and what would that behaviour be? What does a PDEPEND mean for a
> set?

Like virtuals, it makes sense to restrict the dependencies to the
RDEPEND variable as mentioned in glep 37 [1]. I should have
mentioned this earlier since it might not be obvious to some.

>>> Here's an alternate proposal: Repositories can ship sets via files
>>> in sets/*.conf. The format is as described in [1]. In configuration
>>> files, operations applied to a set are applied to anything matching
>>> any spec listed in that set (or any set that set contains, and so
>>> on). On the command line, sets and non-sets cannot be mixed, and
>>> multiple sets cannot be specified.
>>>
>>> [1]: http://paludis.pioto.org/configuration/sets.html
>>>
>> Perhaps can use something like you've got there in addition to the
>> PROPERTIES=set approach.
> 
> Why the need for multiple solutions at all? PROPERTIES=set is too weird
> and involves too much nonsensical behaviour to be useful.

I don't see the PROPERTIES=set approach as being worse than any
other approach for package set definition. It has lots of advantages
because of the way that it fits into the existing ebuild framework
like virtual ebuilds do [1], allowing it to leverage all of the
existing features of the framework (including package.use) and also
allowing it to leverage the tools that have been designed to work
with the framework.

[1] http://www.gentoo.org/proj/en/glep/glep-0037.html
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjgFR4ACgkQ/ejvha5XGaNA5ACfUkefckOusoqkcSFgllZ6gSXu
AP0AoNA4e/r5VxPtdDZtQRTzWDWZIa0U
=GhAY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Bo Ørsted Andresen]

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

On Monday 29 September 2008 01:37:03 Zac Medico wrote:
> > Why the need for multiple solutions at all? PROPERTIES=set is too weird
> > and involves too much nonsensical behaviour to be useful.
>
> I don't see the PROPERTIES=set approach as being worse than any
> other approach for package set definition. It has lots of advantages
> because of the way that it fits into the existing ebuild framework
> like virtual ebuilds do [1], allowing it to leverage all of the
> existing features of the framework (including package.use) and also
> allowing it to leverage the tools that have been designed to work
> with the framework.
>
> [1] http://www.gentoo.org/proj/en/glep/glep-0037.html

I really don't see the advantages of fitting 'into the existing ebuild 
framework like virtual ebuilds do'. Can you name any real advantages to it? 
Having virtuals as ebuilds makes sense because ebuilds need to depend upon 
them. But I can see no decent use case for letting a non-set ebuild depend 
upon a set. As far as I'm concerned sets are merely a convenience for users. 
It allows them to install, reinstall (mostly of interest for scm ebuilds), 
keyword, unmask, set use flags for or uninstall a set of packages.

-- 
Bo Andresen

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

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bo Ørsted Andresen wrote:
> On Monday 29 September 2008 01:37:03 Zac Medico wrote:
>>> Why the need for multiple solutions at all? PROPERTIES=set is too weird
>>> and involves too much nonsensical behaviour to be useful.
>> I don't see the PROPERTIES=set approach as being worse than any
>> other approach for package set definition. It has lots of advantages
>> because of the way that it fits into the existing ebuild framework
>> like virtual ebuilds do [1], allowing it to leverage all of the
>> existing features of the framework (including package.use) and also
>> allowing it to leverage the tools that have been designed to work
>> with the framework.
>>
>> [1] http://www.gentoo.org/proj/en/glep/glep-0037.html
> 
> I really don't see the advantages of fitting 'into the existing ebuild 
> framework like virtual ebuilds do'. Can you name any real advantages to it? 

This idea initially came up when Jorge (jmbsvicetto) mentioned that
he had used a package set to replace a meta-ebuild in the
desktop-effects overlay, and then users complained that the set did
not supporting the USE conditionals that the previous meta-ebuild
had supported.

Perhaps we can support USE conditionals in sets, but this also seems
to mean that we will need a package.use analog that applies to
package sets. Assuming that we'll need a package.use analog, we
might view the act of replacing meta-packages with sets as a sort of
"throwing the baby out with the bath water" scenario in sense that
meta-packages have lots of useful features and the only reason to
migrate them to sets would be take advantage of the unique features
which sets have to offer. So, rather than force a complete
migration, we may want to consider integrating meta-packages into
the sets framework.

> Having virtuals as ebuilds makes sense because ebuilds need to depend upon 
> them. But I can see no decent use case for letting a non-set ebuild depend 
> upon a set. As far as I'm concerned sets are merely a convenience for users. 
> It allows them to install, reinstall (mostly of interest for scm ebuilds), 
> keyword, unmask, set use flags for or uninstall a set of packages.

The "set use flags" part is interesting. If that's the case, it
seems somewhat ambiguous to use sets to "set use flags" and also
allow sets to contain USE conditionals. Supposing that we do allow
both, are we going to create some analog of package.use for sets, or
not? If we do create such an analog, how would it apply to nested
sets? Should nested sets be able to have separate USE conditional
settings from the sets that nest them?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjhMeIACgkQ/ejvha5XGaN5EgCgp/KWDienRceXkzV5GX4u9wZp
oYEAnRZ7Z8BErZGRNe6muf7fPRLlW/bQ
=RFAJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zac Medico wrote:
> Bo Ørsted Andresen wrote:
>> On Monday 29 September 2008 01:37:03 Zac Medico wrote:
>>>> Why the need for multiple solutions at all? PROPERTIES=set is too weird
>>>> and involves too much nonsensical behaviour to be useful.
>>> I don't see the PROPERTIES=set approach as being worse than any
>>> other approach for package set definition. It has lots of advantages
>>> because of the way that it fits into the existing ebuild framework
>>> like virtual ebuilds do [1], allowing it to leverage all of the
>>> existing features of the framework (including package.use) and also
>>> allowing it to leverage the tools that have been designed to work
>>> with the framework.
>>>
>>> [1] http://www.gentoo.org/proj/en/glep/glep-0037.html
>> I really don't see the advantages of fitting 'into the existing ebuild 
>> framework like virtual ebuilds do'. Can you name any real advantages to it? 
> 
> This idea initially came up when Jorge (jmbsvicetto) mentioned that
> he had used a package set to replace a meta-ebuild in the
> desktop-effects overlay, and then users complained that the set did
> not supporting the USE conditionals that the previous meta-ebuild
> had supported.

For those interested, the complaints were about this meta-ebuild
http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob;f=x11-wm/compiz-fusion/compiz-fusion-0.7.8.ebuild;h=91783ea46143daa90f8102936e170ff43059491b;hb=master
that I replaced with the
http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob;f=sets/compiz-fusion-complete;h=5281e30f5a4677f5f0ef882db9ff187883d569ea;hb=master
and
http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob;f=sets/compiz-fusion;h=8a7869e77ea72f54f9bea6e1b214c124c7025934;hb=master
sets.
Optional deps on the set would allow the user to select whether to
install the gnome or kde backends and to install the unsupported plugins
or not.
Another alternative in this case, is to use the set operators so that I
have a single set for all packages and tell the user to create a set
with the packages he doesn't want to install from the overlay and run
emerge @compiz-fusion-@compiz-fusion-unwanted.

> Perhaps we can support USE conditionals in sets, but this also seems
> to mean that we will need a package.use analog that applies to
> package sets. Assuming that we'll need a package.use analog, we
> might view the act of replacing meta-packages with sets as a sort of
> "throwing the baby out with the bath water" scenario in sense that
> meta-packages have lots of useful features and the only reason to
> migrate them to sets would be take advantage of the unique features
> which sets have to offer. So, rather than force a complete
> migration, we may want to consider integrating meta-packages into
> the sets framework.

Can package.use syntax be extended to allow set entries?
@compiz-fusion -gnome kde kde4

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjhr3sACgkQcAWygvVEyAIs7QCfVZUPK5tV3PxTRPDz18C97Y1d
xFQAn2qNMzPyDUhr0RJDsoWg45MWkJEJ
=TYZC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jorge Manuel B. S. Vicetto wrote:
> Zac Medico wrote:
>> Bo Ørsted Andresen wrote:
>>> On Monday 29 September 2008 01:37:03 Zac Medico wrote:
>>>>> Why the need for multiple solutions at all? PROPERTIES=set is too weird
>>>>> and involves too much nonsensical behaviour to be useful.
>>>> I don't see the PROPERTIES=set approach as being worse than any
>>>> other approach for package set definition. It has lots of advantages
>>>> because of the way that it fits into the existing ebuild framework
>>>> like virtual ebuilds do [1], allowing it to leverage all of the
>>>> existing features of the framework (including package.use) and also
>>>> allowing it to leverage the tools that have been designed to work
>>>> with the framework.
>>>>
>>>> [1] http://www.gentoo.org/proj/en/glep/glep-0037.html
>>> I really don't see the advantages of fitting 'into the existing ebuild 
>>> framework like virtual ebuilds do'. Can you name any real advantages to it? 
>> This idea initially came up when Jorge (jmbsvicetto) mentioned that
>> he had used a package set to replace a meta-ebuild in the
>> desktop-effects overlay, and then users complained that the set did
>> not supporting the USE conditionals that the previous meta-ebuild
>> had supported.
> 
> For those interested, the complaints were about this meta-ebuild
> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob;f=x11-wm/compiz-fusion/compiz-fusion-0.7.8.ebuild;h=91783ea46143daa90f8102936e170ff43059491b;hb=master
> that I replaced with the
> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob;f=sets/compiz-fusion-complete;h=5281e30f5a4677f5f0ef882db9ff187883d569ea;hb=master
> and
> http://git.overlays.gentoo.org/gitweb/?p=proj/desktop-effects.git;a=blob;f=sets/compiz-fusion;h=8a7869e77ea72f54f9bea6e1b214c124c7025934;hb=master
> sets.
> Optional deps on the set would allow the user to select whether to
> install the gnome or kde backends and to install the unsupported plugins
> or not.

Let's be clear about what you mean by "optional". In this case I
think you mean "conditional upon USE flag settings".

> Another alternative in this case, is to use the set operators so that I
> have a single set for all packages and tell the user to create a set
> with the packages he doesn't want to install from the overlay and run
> emerge @compiz-fusion-@compiz-fusion-unwanted.

It seems to me that users will generally want something more
persistent than that, in order for world updates and --depclean
operations work as expected. In order to make it persistent the user
could use set configuration files to subtract the unwanted atoms
from @compiz-fusion, yet still be able to refer to it as
@compiz-fusion and have @compiz-fusion listed in
/var/lib/portage/world_sets.

>> Perhaps we can support USE conditionals in sets, but this also seems
>> to mean that we will need a package.use analog that applies to
>> package sets. Assuming that we'll need a package.use analog, we
>> might view the act of replacing meta-packages with sets as a sort of
>> "throwing the baby out with the bath water" scenario in sense that
>> meta-packages have lots of useful features and the only reason to
>> migrate them to sets would be take advantage of the unique features
>> which sets have to offer. So, rather than force a complete
>> migration, we may want to consider integrating meta-packages into
>> the sets framework.
> 
> Can package.use syntax be extended to allow set entries?
> @compiz-fusion -gnome kde kde4

Perhaps, but we need to clarify how that sort of setting will affect
nested sets. For example, if @compiz-fusion contains nested sets,
would those USE settings apply to the nested sets as well? Will
nested sets be allowed to have independent USE settings from the
sets that nest them?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjhucAACgkQ/ejvha5XGaPzJQCeKGHC4mC2hEFiVSYeP43w9oAv
a9sAoJY9JWjMugzRv6GMSDzbrABmRaSV
=W1wj
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ryan Hill]

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

On Mon, 29 Sep 2008 22:31:46 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> > Can package.use syntax be extended to allow set entries?
> > @compiz-fusion -gnome kde kde4
> 
> Perhaps, but we need to clarify how that sort of setting will affect
> nested sets. For example, if @compiz-fusion contains nested sets,
> would those USE settings apply to the nested sets as well? Will
> nested sets be allowed to have independent USE settings from the
> sets that nest them?

Maybe a nested set could inherit the USE flag settings of its parent set
unless it has its own entry in package.use.

Though what happens if a package is in both sets which have
conflicting flags in package.use?  I would say that the nested set has
to have priority.  If not, I can easily imagine people getting confused
when their USE settings for a set are being applied to all but
one or two packages.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Hill wrote:
> On Mon, 29 Sep 2008 22:31:46 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> 
>>> Can package.use syntax be extended to allow set entries?
>>> @compiz-fusion -gnome kde kde4
>> Perhaps, but we need to clarify how that sort of setting will affect
>> nested sets. For example, if @compiz-fusion contains nested sets,
>> would those USE settings apply to the nested sets as well? Will
>> nested sets be allowed to have independent USE settings from the
>> sets that nest them?
> 
> Maybe a nested set could inherit the USE flag settings of its parent set
> unless it has its own entry in package.use.
> 
> Though what happens if a package is in both sets which have
> conflicting flags in package.use?  I would say that the nested set has
> to have priority.  If not, I can easily imagine people getting confused
> when their USE settings for a set are being applied to all but
> one or two packages.

It seems to me that the most logical approach would be to do some
sort of "incremental" stacking, similar to the way that USE flags
stack in the profiles. Suppose that we have the following settings
in package.use:

 @kde-meta    foo bar
 @kdeedu-meta -foo

If the flags are stacked incrementally, analogously to the way that
they are stacked in profiles, then the above setting would apply the
"foo" and "bar" flags to all of @kde-meta except for the
@kdeedu-meta subset which would only have "bar" applied since "foo"
has been disabled incrementally. Does this approach seem reasonable?
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjjp0QACgkQ/ejvha5XGaNRUQCfcobuk6BFdlZgGrb/jVyAb87P
0goAn1gJp+Q2kdPaGtpmQwn/G5+yKTqU
=TJdF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zac Medico wrote:
> Ryan Hill wrote:
>> On Mon, 29 Sep 2008 22:31:46 -0700
>> Zac Medico <zmedico@gentoo.org> wrote:
> 
>>>> Can package.use syntax be extended to allow set entries?
>>>> @compiz-fusion -gnome kde kde4
>>> Perhaps, but we need to clarify how that sort of setting will affect
>>> nested sets. For example, if @compiz-fusion contains nested sets,
>>> would those USE settings apply to the nested sets as well? Will
>>> nested sets be allowed to have independent USE settings from the
>>> sets that nest them?
>> Maybe a nested set could inherit the USE flag settings of its parent set
>> unless it has its own entry in package.use.
> 
>> Though what happens if a package is in both sets which have
>> conflicting flags in package.use?  I would say that the nested set has
>> to have priority.  If not, I can easily imagine people getting confused
>> when their USE settings for a set are being applied to all but
>> one or two packages.
> 
> It seems to me that the most logical approach would be to do some
> sort of "incremental" stacking, similar to the way that USE flags
> stack in the profiles. Suppose that we have the following settings
> in package.use:
> 
>  @kde-meta    foo bar
>  @kdeedu-meta -foo
> 
> If the flags are stacked incrementally, analogously to the way that
> they are stacked in profiles, then the above setting would apply the
> "foo" and "bar" flags to all of @kde-meta except for the
> @kdeedu-meta subset which would only have "bar" applied since "foo"
> has been disabled incrementally. Does this approach seem reasonable?

This sounds a good approach.

Ryan, I disagree with your proposal. If I enable a use flag for the
"meta" @kde and also disable it for @kdenetwork, I don't expect my
option for the @kde "meta" to override my option for @kdenetwork.
As Zac proposed, an incremental stack makes more sense. Before we had
sets, when we enabled a use flag for a meta and disabled it for an
ebuild pulled by the meta, we never expected the option for the ebuild
to be overridden by the option for the meta.

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjkN0kACgkQcAWygvVEyAK2iQCcDgNPwNlgw3MfV1WZj+S6L+xW
RZ4An0UONUAt60WeQAUbDk2rEMduUub9
=VYib
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ryan Hill]

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

On Thu, 02 Oct 2008 02:51:53 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:

> Zac Medico wrote:
> > Ryan Hill wrote:

> >> Though what happens if a package is in both sets which have
> >> conflicting flags in package.use?  I would say that the nested set
> >> has to have priority.  If not, I can easily imagine people getting
> >> confused when their USE settings for a set are being applied to
> >> all but one or two packages.

> > It seems to me that the most logical approach would be to do some
> > sort of "incremental" stacking, similar to the way that USE flags
> > stack in the profiles. Suppose that we have the following settings
> > in package.use:
> > 
> >  @kde-meta    foo bar
> >  @kdeedu-meta -foo
> > 
> > If the flags are stacked incrementally, analogously to the way that
> > they are stacked in profiles, then the above setting would apply the
> > "foo" and "bar" flags to all of @kde-meta except for the
> > @kdeedu-meta subset which would only have "bar" applied since "foo"
> > has been disabled incrementally. Does this approach seem reasonable?

> This sounds a good approach.
> 
> Ryan, I disagree with your proposal. If I enable a use flag for the
> "meta" @kde and also disable it for @kdenetwork, I don't expect my
> option for the @kde "meta" to override my option for @kdenetwork.
> As Zac proposed, an incremental stack makes more sense. Before we had
> sets, when we enabled a use flag for a meta and disabled it for an
> ebuild pulled by the meta, we never expected the option for the ebuild
> to be overridden by the option for the meta.

Yes, that's what I said.  ;)

The nested set's flags (@kde-network) override the parent set's flags
(@kde).


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ryan Hill]

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

On Sat, 4 Oct 2008 00:05:53 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Thu, 02 Oct 2008 02:51:53 +0000
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:

> > Ryan, I disagree with your proposal. If I enable a use flag for the
> > "meta" @kde and also disable it for @kdenetwork, I don't expect my
> > option for the @kde "meta" to override my option for @kdenetwork.
> > As Zac proposed, an incremental stack makes more sense. Before we
> > had sets, when we enabled a use flag for a meta and disabled it for
> > an ebuild pulled by the meta, we never expected the option for the
> > ebuild to be overridden by the option for the meta.

> Yes, that's what I said.  ;)
> 
> The nested set's flags (@kde-network) override the parent set's flags
> (@kde).

Though I'm still not sure what happens when a package is in two
unrelated sets..

@gnome:
   RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2"

@xfce4:
   RDEPEND="gnome-extra/gnome-screensaver"

package.use:
@gnome             opengl
@xfce              -opengl


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Hill wrote:
> Though I'm still not sure what happens when a package is in two
> unrelated sets..
> 
> @gnome:
>    RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2"
> 
> @xfce4:
>    RDEPEND="gnome-extra/gnome-screensaver"
> 
> package.use:
> @gnome             opengl
> @xfce              -opengl
> 

I suppose we could use the order that they are listed in package.use
to apply the incremental stacking, so opengl would be disabled since
@xfce comes after @gnome.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjnpRAACgkQ/ejvha5XGaMhCACfcCqqfRl6sLXbXsc9k/8yMg90
JqkAoLWCVoH2Jf+6RRAd0CnlLsl82SSO
=alvy
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Ryan Hill]

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

On Sat, 04 Oct 2008 10:17:05 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ryan Hill wrote:
> > Though I'm still not sure what happens when a package is in two
> > unrelated sets..
> > 
> > @gnome:
> >    RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2"
> > 
> > @xfce4:
> >    RDEPEND="gnome-extra/gnome-screensaver"
> > 
> > package.use:
> > @gnome             opengl
> > @xfce              -opengl
> > 
> 
> I suppose we could use the order that they are listed in package.use
> to apply the incremental stacking, so opengl would be disabled since
> @xfce comes after @gnome.

I guess I'll need to stop sorting my package.use then. :p

But yeah, I have no better idea.  If someone really needs to lock down
a USE flag on a pkg they can put the pkg atom itself into p.use.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Steve Long]

Ryan Hill wrote:

> Zac Medico <zmedico@gentoo.org> wrote:
>> Ryan Hill wrote:
>> > Though I'm still not sure what happens when a package is in two
>> > unrelated sets..
>> > 
>> > @gnome:
>> >    RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2"
>> > 
>> > @xfce4:
>> >    RDEPEND="gnome-extra/gnome-screensaver"
>> > 
>> > package.use:
>> > @gnome             opengl
>> > @xfce              -opengl
>> 
>> I suppose we could use the order that they are listed in package.use
>> to apply the incremental stacking, so opengl would be disabled since
>> @xfce comes after @gnome.
> 
> I guess I'll need to stop sorting my package.use then. :p
> 
> But yeah, I have no better idea.  If someone really needs to lock down
> a USE flag on a pkg they can put the pkg atom itself into p.use.
> 
Indeed, although a more natural approach might be to take whichever
dependency is more specific (in the case where the user hasn't otherwise
expressed a preference, and there is a conflict.) The more specific dep
implies a closer relationship (although a warning would be useful ofc.)

Another way to express preference or association might be useful too,
although a category heuristic would also aid automated decision-making (the
set is being considered, so I'm guessing we know, which packages are listed
in it; can easily query if not.) The fallback would be the simple position
in the list.

While this might sound like yet more special-casing it's the kind of thing
that delights users ime, since it means less for them to worry about, and
only runs in the case where the decision is not clear from the
configuration and the tree. IOW something to specify as a 'may' rather
than 'undefined.'

(I still feel the same about losing 'world' ofc *sniff* ;)

Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Robert Bridge]

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

On Wed, 01 Oct 2008 09:37:25 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ryan Hill wrote:
> > On Mon, 29 Sep 2008 22:31:46 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> > 
> >>> Can package.use syntax be extended to allow set entries?
> >>> @compiz-fusion -gnome kde kde4
> >> Perhaps, but we need to clarify how that sort of setting will
> >> affect nested sets. For example, if @compiz-fusion contains nested
> >> sets, would those USE settings apply to the nested sets as well?
> >> Will nested sets be allowed to have independent USE settings from
> >> the sets that nest them?
> > 
> > Maybe a nested set could inherit the USE flag settings of its
> > parent set unless it has its own entry in package.use.
> > 
> > Though what happens if a package is in both sets which have
> > conflicting flags in package.use?  I would say that the nested set
> > has to have priority.  If not, I can easily imagine people getting
> > confused when their USE settings for a set are being applied to all
> > but one or two packages.
> 
> It seems to me that the most logical approach would be to do some
> sort of "incremental" stacking, similar to the way that USE flags
> stack in the profiles. Suppose that we have the following settings
> in package.use:
> 
>  @kde-meta    foo bar
>  @kdeedu-meta -foo
> 
> If the flags are stacked incrementally, analogously to the way that
> they are stacked in profiles, then the above setting would apply the
> "foo" and "bar" flags to all of @kde-meta except for the
> @kdeedu-meta subset which would only have "bar" applied since "foo"
> has been disabled incrementally. Does this approach seem reasonable?

From a lowly users perspective, I would say this is more intuitive. It
fits with the expected policy of the closest flag to the package taking
precedence...

Rob.

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

[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Duncan]

Zac Medico <zmedico@gentoo.org> posted 48E00B9B.3060600@gentoo.org,
excerpted below, on  Sun, 28 Sep 2008 15:56:27 -0700:

> For example, `emerge kde-meta` would behave as as normal meta-package
> currently does, and `emerge @kde-meta` would reference the same package
> as a set and could thereby trigger different behavior which is
> appropriate for a set.

Ahh... that's rather clearer now.  Somehow I missed that bit before.

However, it seems to me we'd have some of the same types of issues we've 
previously discussed over the distinction between world and @world.  It's 
going to be virtually impossible to get some users to see the difference, 
with the consequence being that they use the wrong reference (probably 
skipping the @ as unnecessary typing) and end up with (to them) 
completely unexpected behaviour.  How long have we been drilling into 
users' heads that they need to use --pretend (or --ask) --verbose to 
check that what they intend is really what's going to happen?  Yet I just 
dealt with a case the other day where someone ended up with something 
entirely (to them) unexpected, because they failed to preview what was 
going to happen, first.

Going out of our way to (effectively) make things even /more/ confusing 
by deliberately creating set-packages that can be referred to as either, 
with different behavior in each case, would seem to be the equivalent of 
deliberately setting traps for those poor users.  (Yes, they /should/ 
know the difference and it's a PEBCAK if they don't/won't, but 
unfortunately that PEBCAK is/can-safely-be-predicted-to-be rather 
common...)

So sure, we can institute it as suggested, damn the torpedos, but I 
believe it's safely predictable that come a few months hence, after we've 
dealt with our tenth person to end up screwing their system as a result, 
we're going to rue the day...  Never-the-less, it's not my decision.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Zac Medico <zmedico@gentoo.org> posted 48E00B9B.3060600@gentoo.org,
> excerpted below, on  Sun, 28 Sep 2008 15:56:27 -0700:
> 
>> For example, `emerge kde-meta` would behave as as normal meta-package
>> currently does, and `emerge @kde-meta` would reference the same package
>> as a set and could thereby trigger different behavior which is
>> appropriate for a set.
> 
> Ahh... that's rather clearer now.  Somehow I missed that bit before.
> 
> However, it seems to me we'd have some of the same types of issues we've 
> previously discussed over the distinction between world and @world.  It's 
> going to be virtually impossible to get some users to see the difference, 
> with the consequence being that they use the wrong reference (probably 
> skipping the @ as unnecessary typing) and end up with (to them) 
> completely unexpected behaviour.  How long have we been drilling into 
> users' heads that they need to use --pretend (or --ask) --verbose to 
> check that what they intend is really what's going to happen?  Yet I just 
> dealt with a case the other day where someone ended up with something 
> entirely (to them) unexpected, because they failed to preview what was 
> going to happen, first.

I'm not suggesting that the ebuild and the package set necessarily
need to have the same name. What I'm suggesting is that we use a
configuration file, distributed with the ebuild repository, to map
set names to ebuilds. This mapping would make the set name
independent from the ebuild name.

> Going out of our way to (effectively) make things even /more/ confusing 
> by deliberately creating set-packages that can be referred to as either, 
> with different behavior in each case, would seem to be the equivalent of 
> deliberately setting traps for those poor users.  (Yes, they /should/ 
> know the difference and it's a PEBCAK if they don't/won't, but 
> unfortunately that PEBCAK is/can-safely-be-predicted-to-be rather 
> common...)
> 
> So sure, we can institute it as suggested, damn the torpedos, but I 
> believe it's safely predictable that come a few months hence, after we've 
> dealt with our tenth person to end up screwing their system as a result, 
> we're going to rue the day...  Never-the-less, it's not my decision.
> 

I don't expect users to have much trouble with this concept, and
they don't even have to use sets unless they want to make use of the
additional features that sets provide.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjgeEkACgkQ/ejvha5XGaOObQCghFkrhJiTVXAerwJXRbKJxk7R
yKsAmgIWp1VAA2glNuQ+pa6U8OjnYszq
=HzsM
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Duncan]

Zac Medico <zmedico@gentoo.org> posted 48E0784A.2040505@gentoo.org,
excerpted below, on  Sun, 28 Sep 2008 23:40:10 -0700:

> I'm not suggesting that the ebuild and the package set necessarily need
> to have the same name. What I'm suggesting is that we use a
> configuration file, distributed with the ebuild repository, to map set
> names to ebuilds. This mapping would make the set name independent from
> the ebuild name.

That should work... and it could be as simple as the ebuild name, plus 
-set, so for example kde-meta and @kde-meta-set.  If users mess /that/ 
up... is there any hope for them?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Rémi Cardona]

Zac Medico a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi everyone,
>
> Please consider a PROPERTIES=set value that allows an ebuild to
> indicate that it should behave like a package set when selected on
> the command line. This is behavior is somewhat difficult to describe
> in words but the following example should be sufficient to convey
> the general idea.

As one of the maintainers of the gnome-base/gnome meta, I fail to see 
the usefulness of such a change. We have yet to ask users to rebuild 
"gnome" completely. Do you have any specific use cases (maybe coming 
from the KDE herd, since you used the kde meta as an example) ?

The one thing that bothers me about this is consistency: if, say, xfce 
(let's change ;) ) decides to use PROPERTIES=set, users will have a 
different experience with their ebuild than with the other metas we 
currently ship.

All in all, I'm not really against such a change, however I really fail 
to see the win for everyone, end-users included.

Cheers :)

Rémi

Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rémi Cardona wrote:
> Zac Medico a écrit :
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi everyone,
>>
>> Please consider a PROPERTIES=set value that allows an ebuild to
>> indicate that it should behave like a package set when selected on
>> the command line. This is behavior is somewhat difficult to describe
>> in words but the following example should be sufficient to convey
>> the general idea.
> 
> As one of the maintainers of the gnome-base/gnome meta, I fail to see
> the usefulness of such a change. We have yet to ask users to rebuild
> "gnome" completely. Do you have any specific use cases (maybe coming
> from the KDE herd, since you used the kde meta as an example) ?
> 
> The one thing that bothers me about this is consistency: if, say, xfce
> (let's change ;) ) decides to use PROPERTIES=set, users will have a
> different experience with their ebuild than with the other metas we
> currently ship.
> 
> All in all, I'm not really against such a change, however I really fail
> to see the win for everyone, end-users included.

Over the course of the discussion I've revised the idea so that it
essentially represents a way to define a package set, without any
changes to existing behavior. What will change is that we will have
a new way to define package sets, based on ebuilds.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjgdqIACgkQ/ejvha5XGaP2qwCg8RgPOtwHrF/IkPm61irpeYQs
918AoMGto/juGcI9og4Ct/dgkymIHz7V
=3uaT
-----END PGP SIGNATURE-----

[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Steve Long]

Zac Medico wrote:

> Rémi Cardona wrote:
>> Zac Medico a écrit :
>>> Please consider a PROPERTIES=set value that allows an ebuild to
>>> indicate that it should behave like a package set when selected on
>>> the command line. This is behavior is somewhat difficult to describe
>>> in words but the following example should be sufficient to convey
>>> the general idea.
>> 
>> As one of the maintainers of the gnome-base/gnome meta, I fail to see
>> the usefulness of such a change. We have yet to ask users to rebuild
>> "gnome" completely. Do you have any specific use cases (maybe coming
>> from the KDE herd, since you used the kde meta as an example) ?
>> 
>> The one thing that bothers me about this is consistency: if, say, xfce
>> (let's change ;) ) decides to use PROPERTIES=set, users will have a
>> different experience with their ebuild than with the other metas we
>> currently ship.
>>
Only when they consciously use the set syntax, surely?
 
>> All in all, I'm not really against such a change, however I really fail
>> to see the win for everyone, end-users included.
> 
> Over the course of the discussion I've revised the idea so that it
> essentially represents a way to define a package set, without any
> changes to existing behavior. What will change is that we will have
> a new way to define package sets, based on ebuilds.

Makes sense to me, though not sure you need the mapping file. I'm perfectly
happy about emerge -uDN @kde-meta say, updating all kde-meta packages I
might have installed; I take it that after emerge kde-meta to install, and
then removing some of the packages, the user could continue to reference
the set for upgrade, without portage reinstalling those?

Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Long wrote:
> Zac Medico wrote:
> 
>> Rémi Cardona wrote:
>>> Zac Medico a écrit :
>>>> Please consider a PROPERTIES=set value that allows an ebuild to
>>>> indicate that it should behave like a package set when selected on
>>>> the command line. This is behavior is somewhat difficult to describe
>>>> in words but the following example should be sufficient to convey
>>>> the general idea.
>>> As one of the maintainers of the gnome-base/gnome meta, I fail to see
>>> the usefulness of such a change. We have yet to ask users to rebuild
>>> "gnome" completely. Do you have any specific use cases (maybe coming
>>> from the KDE herd, since you used the kde meta as an example) ?
>>>
>>> The one thing that bothers me about this is consistency: if, say, xfce
>>> (let's change ;) ) decides to use PROPERTIES=set, users will have a
>>> different experience with their ebuild than with the other metas we
>>> currently ship.
>>>
> Only when they consciously use the set syntax, surely?

Right.

>>> All in all, I'm not really against such a change, however I really fail
>>> to see the win for everyone, end-users included.
>> Over the course of the discussion I've revised the idea so that it
>> essentially represents a way to define a package set, without any
>> changes to existing behavior. What will change is that we will have
>> a new way to define package sets, based on ebuilds.
> 
> Makes sense to me, though not sure you need the mapping file. I'm perfectly
> happy about emerge -uDN @kde-meta say, updating all kde-meta packages I
> might have installed; I take it that after emerge kde-meta to install, and
> then removing some of the packages, the user could continue to reference
> the set for upgrade, without portage reinstalling those?

That would be a set subtraction operation, so the user would use a
configuration file to configure the set so that certain unwanted
atoms are automatically subtracted out. Alternatively, we could
implement a syntax extension for "optional atoms" that are only
pulled into the dependency graph if they happen to be installed already.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjhOnQACgkQ/ejvha5XGaMj1QCfRzl74HWG/s4nuf7pqIiZ8sEt
77IAn18mFmdmc3JCOJil2S1NPJcEe1wX
=M2k9
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

[Steve Long]

Zac Medico wrote:

> Steve Long wrote:
>> Zac Medico wrote:
>>> Rémi Cardona wrote:
>>>> As one of the maintainers of the gnome-base/gnome meta, I fail to see
>>>> the usefulness of such a change. We have yet to ask users to rebuild
>>>> "gnome" completely. Do you have any specific use cases (maybe coming
>>>> from the KDE herd, since you used the kde meta as an example) ?
>>>>
>>> Over the course of the discussion I've revised the idea so that it
>>> essentially represents a way to define a package set, without any
>>> changes to existing behavior. What will change is that we will have
>>> a new way to define package sets, based on ebuilds.
>> 
>> Makes sense to me, though not sure you need the mapping file. I'm
>> perfectly happy about emerge -uDN @kde-meta say, updating all kde-meta
>> packages I might have installed; I take it that after emerge kde-meta to
>> install, and then removing some of the packages, the user could continue
>> to reference the set for upgrade, without portage reinstalling those?
> 
> That would be a set subtraction operation, so the user would use a
> configuration file to configure the set so that certain unwanted
> atoms are automatically subtracted out. Alternatively, we could
> implement a syntax extension for "optional atoms" that are only
> pulled into the dependency graph if they happen to be installed already.
> 
It would be nice to address it; wrt people installing a meta which will
define a set, it'd make it easier to maintain (a box) if the set syntax
referred to whatever was installed, whereas emerging the package would
install all its deps as a standard virtual does (in the default setting.)

Integrating seems like a good idea, wrt to the USE settings you discussed in
the other thread. There is already a framework in place to model all that,
and more, so might as well use it. (I'd vote for allowing as much
flexibility as the ebuild author wants to specify.)