FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Portage Developer

 
 
LinkBack Thread Tools
 
Old 10-03-2008, 07:10 AM
Zac Medico
 
Default PROPERTIES=set for meta-packages that should behave like package sets (revised)

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

Hi everyone,

This is a revised version of the PROPERTIES=set proposal which has
been discussed previously [1].

Please consider a PROPERTIES=set value will serve to indicate that a
given ebuild should be exposed within the package set framework as a
package set. In order to expose such an ebuild as a package set, a
new "sets" profile configuration file will serve to define mappings
from set names to package atoms. Similar to the existing "virtuals"
file which is already supported by profiles, the "sets" file will
allow a given profile to override any mappings that have been
defined by parent profiles. The bulk of the mappings will be defined
in profiles/base/sets, since all profiles should inherit the same
set mappings unless they need to be overridden for some reason.

For the new "sets" profile configuration file format, the simplest
possible layout could have a set name in the first column and a
package atom in the second column. The package atom should match an
ebuild which exhibits the "set" property. In addition to the set
name and atom columns, we may also want to include an EAPI column
which the package manager can use to ensure that it parses the atom
syntax correctly.

Similar to the proposed "virtual" property [2], the "set" property
will indicate that dependency calculations should consider the
ebuild to have zero installation cost. Similar to glep 37 [3],
ebuilds that exhibit PROPERTIES=set should also define all of their
dependencies in the RDEPEND variable. Other than these constraints,
an ebuild which exhibits PROPERTIES=set 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.

I order to determine which atoms correspond to a given set, the
first step is to lookup the set name from the profile's "sets"
configuration files. The corresponding package atom is then resolved
to a specific ebuild which should exhibit the "set" property. The
dependency atoms from this ebuild's RDEPEND variable will serve to
make up the atoms of the package set. In cases when these atoms
resolve to other ebuilds that exhibit he "set" property then those
other ebuilds act as nested sets and this nesting process is
recursive with no limit on the depth of nesting. The nested sets do
not necessarily have to be mapped to specific set names by the
profile's "sets" configuration files. If nested sets are anonymous
in this sense then their atoms still become a part of the set that
they are nested within, just as they would if they had been given a
name by the profile's "sets" configuration files.

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

[1]
http://archives.gentoo.org/gentoo-dev/msg_02020c2650449920c941adf46dbf7d6f.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml
[3] http://archives.gentoo.org/proj/en/glep/glep-0037.html
- --
Thanks,
Zac


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

iEYEARECAAYFAkjlxX4ACgkQ/ejvha5XGaMv2gCggj2YCW3MkcW/Y/EQUPX+V38E
4DgAnR3d4mD5Y4S2qGZRbq8md1NJnLE7
=AdHx
-----END PGP SIGNATURE-----
 
Old 10-03-2008, 07:10 AM
Zac Medico
 
Default PROPERTIES=set for meta-packages that should behave like package sets (revised)

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

Hi everyone,

This is a revised version of the PROPERTIES=set proposal which has
been discussed previously [1].

Please consider a PROPERTIES=set value will serve to indicate that a
given ebuild should be exposed within the package set framework as a
package set. In order to expose such an ebuild as a package set, a
new "sets" profile configuration file will serve to define mappings
from set names to package atoms. Similar to the existing "virtuals"
file which is already supported by profiles, the "sets" file will
allow a given profile to override any mappings that have been
defined by parent profiles. The bulk of the mappings will be defined
in profiles/base/sets, since all profiles should inherit the same
set mappings unless they need to be overridden for some reason.

For the new "sets" profile configuration file format, the simplest
possible layout could have a set name in the first column and a
package atom in the second column. The package atom should match an
ebuild which exhibits the "set" property. In addition to the set
name and atom columns, we may also want to include an EAPI column
which the package manager can use to ensure that it parses the atom
syntax correctly.

Similar to the proposed "virtual" property [2], the "set" property
will indicate that dependency calculations should consider the
ebuild to have zero installation cost. Similar to glep 37 [3],
ebuilds that exhibit PROPERTIES=set should also define all of their
dependencies in the RDEPEND variable. Other than these constraints,
an ebuild which exhibits PROPERTIES=set 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.

I order to determine which atoms correspond to a given set, the
first step is to lookup the set name from the profile's "sets"
configuration files. The corresponding package atom is then resolved
to a specific ebuild which should exhibit the "set" property. The
dependency atoms from this ebuild's RDEPEND variable will serve to
make up the atoms of the package set. In cases when these atoms
resolve to other ebuilds that exhibit he "set" property then those
other ebuilds act as nested sets and this nesting process is
recursive with no limit on the depth of nesting. The nested sets do
not necessarily have to be mapped to specific set names by the
profile's "sets" configuration files. If nested sets are anonymous
in this sense then their atoms still become a part of the set that
they are nested within, just as they would if they had been given a
name by the profile's "sets" configuration files.

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

[1]
http://archives.gentoo.org/gentoo-dev/msg_02020c2650449920c941adf46dbf7d6f.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_9d449a18a96a25a547fcfd40544085cf.xml
[3] http://archives.gentoo.org/proj/en/glep/glep-0037.html
- --
Thanks,
Zac


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

iEYEARECAAYFAkjlxX4ACgkQ/ejvha5XGaMv2gCggj2YCW3MkcW/Y/EQUPX+V38E
4DgAnR3d4mD5Y4S2qGZRbq8md1NJnLE7
=AdHx
-----END PGP SIGNATURE-----
 
Old 10-03-2008, 03:15 PM
Ciaran McCreesh
 
Default PROPERTIES=set for meta-packages that should behave like package sets (revised)

On Fri, 03 Oct 2008 00:10:56 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> For the new "sets" profile configuration file format, the simplest
> possible layout could have a set name in the first column and a
> package atom in the second column. The package atom should match an
> ebuild which exhibits the "set" property. In addition to the set
> name and atom columns, we may also want to include an EAPI column
> which the package manager can use to ensure that it parses the atom
> syntax correctly.

We probably want to start putting a profile_eapi file in each profile
directory or something like that... Get package managers to refuse to
use any profile that contains a directory using an eapi it doesn't
know. This'll help sort out the slot deps in profiles issue too.

> Similar to the proposed "virtual" property [2], the "set" property
> will indicate that dependency calculations should consider the
> ebuild to have zero installation cost.

If we go this route, that needs to be a property of its own, really.
Otherwise we'll end up with a dozen properties all of which imply
particular different real properties.

> I order to determine which atoms correspond to a given set, the
> first step is to lookup the set name from the profile's "sets"
> configuration files. The corresponding package atom is then resolved
> to a specific ebuild which should exhibit the "set" property. The
> dependency atoms from this ebuild's RDEPEND variable will serve to
> make up the atoms of the package set. In cases when these atoms
> resolve to other ebuilds that exhibit he "set" property then those
> other ebuilds act as nested sets and this nesting process is
> recursive with no limit on the depth of nesting. The nested sets do
> not necessarily have to be mapped to specific set names by the
> profile's "sets" configuration files. If nested sets are anonymous
> in this sense then their atoms still become a part of the set that
> they are nested within, just as they would if they had been given a
> name by the profile's "sets" configuration files.

Why not just invent a syntax that lets you take an arbitrary ebuild
and use an arbitrary dep key from it as a set? Say, something like
@RDEPEND(=foo/bar-1.23) . No need for any PROPERTIES or mapping
mess at all...

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

This looks to me as if you're trying to find uses for PROPERTIES,
rather than trying to find ways to solve a problem.

--
Ciaran McCreesh
 
Old 10-03-2008, 03:53 PM
Zac Medico
 
Default PROPERTIES=set for meta-packages that should behave like package sets (revised)

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

Ciaran McCreesh wrote:
> On Fri, 03 Oct 2008 00:10:56 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> For the new "sets" profile configuration file format, the simplest
>> possible layout could have a set name in the first column and a
>> package atom in the second column. The package atom should match an
>> ebuild which exhibits the "set" property. In addition to the set
>> name and atom columns, we may also want to include an EAPI column
>> which the package manager can use to ensure that it parses the atom
>> syntax correctly.
>
> We probably want to start putting a profile_eapi file in each profile
> directory or something like that... Get package managers to refuse to
> use any profile that contains a directory using an eapi it doesn't
> know. This'll help sort out the slot deps in profiles issue too.

That's a good idea. If we do that then we can assume that all atoms
in the profile conform to the specified EAPI.

>> Similar to the proposed "virtual" property [2], the "set" property
>> will indicate that dependency calculations should consider the
>> ebuild to have zero installation cost.
>
> If we go this route, that needs to be a property of its own, really.
> Otherwise we'll end up with a dozen properties all of which imply
> particular different real properties.

Perhaps, but there's a trade-off in having to specify two properties
when a single property can have compound meaning. For example,
Donnie (dberkholz) has previously expressed some concern about
PROPERTIES being more fine-grained than they need to be [1].

>> I order to determine which atoms correspond to a given set, the
>> first step is to lookup the set name from the profile's "sets"
>> configuration files. The corresponding package atom is then resolved
>> to a specific ebuild which should exhibit the "set" property. The
>> dependency atoms from this ebuild's RDEPEND variable will serve to
>> make up the atoms of the package set. In cases when these atoms
>> resolve to other ebuilds that exhibit he "set" property then those
>> other ebuilds act as nested sets and this nesting process is
>> recursive with no limit on the depth of nesting. The nested sets do
>> not necessarily have to be mapped to specific set names by the
>> profile's "sets" configuration files. If nested sets are anonymous
>> in this sense then their atoms still become a part of the set that
>> they are nested within, just as they would if they had been given a
>> name by the profile's "sets" configuration files.
>
> Why not just invent a syntax that lets you take an arbitrary ebuild
> and use an arbitrary dep key from it as a set? Say, something like
> @RDEPEND(=foo/bar-1.23) . No need for any PROPERTIES or mapping
> mess at all...

Well, that wouldn't allow for nesting. The idea behind the
PROPERTIES=set approach is to integrate meta-ebuilds into the sets
framework in a way maximizes reuse of the advantages that
meta-ebuilds have to offer [2].

>> Does this seem like a good approach? Are there any suggestions for
>> improvements or alternative approaches?
>
> This looks to me as if you're trying to find uses for PROPERTIES,
> rather than trying to find ways to solve a problem.

No, I'm trying to integrate meta-ebuilds into the sets framework and
it just happens the PROPERTIES metadata offers a convenient way to
separate meta-ebuilds from normal ebuilds.

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

iEYEARECAAYFAkjmQBAACgkQ/ejvha5XGaP4sgCdEWuCSpUZKTwxKxOxZOTEIn3R
bgkAnROJHVeYYG5K7rorJloHjvjNUkAe
=fZP5
-----END PGP SIGNATURE-----
 
Old 10-04-2008, 03:46 AM
"Jorge Manuel B. S. Vicetto"
 
Default PROPERTIES=set for meta-packages that should behave like package sets (revised)

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

Zac Medico wrote:
> Hi everyone,
>
> This is a revised version of the PROPERTIES=set proposal which has
> been discussed previously [1].
>
< snip a detailed proposal about a new kind of set>

Let me try show some real examples of the type of sets I would like to
use and how I'd like to use them, so that your proposal and the
discussion on sets can take this into account.

"meta" sets:
- ---- @kde ----
# We don't include kdesdk on the global set
kde-base/kate

@kdeadmin
@kdeartwork
@kdebase
@kdeedu
@kdegames
@kdegraphics
@kdemultimedia
@kdenetwork
@kdepim
@kdetoys
@kdeutils
- ---- @kde ----

simple sets (list of ebuilds)
- ---- @kdetoys ----
kde-base/amor
kde-base/kteatime
kde-base/ktux
kde-base/kweather
- ---- @kdetoys ----

sets with conditional deps
- ---- @compiz-fusion ----
dev-python/compizconfig-python
x11-apps/ccsm
x11-apps/simple-ccsm
x11-libs/compiz-bcop
x11-libs/libcompizconfig
x11-plugins/compiz-fusion-plugins-main
x11-plugins/compiz-fusion-plugins-extra
x11-themes/emerald-themes
x11-wm/compiz
emerald? (x11-wm/emerald )
gnome? ( x11-libs/compizconfig-backend-gconf )
kde? ( x11-libs/compizconfig-backend-kconfig )
unsupported? ( x11-plugins/compiz-fusion-plugins-unsupported )
- ---- @compiz-fusion ----

It would also be important to have versioned sets (depending on a slot,
for example). Marius Mauch (genone) suggested a very interesting way to
solve this by using a set config file (portage specific) that, as he
stated, "should work if I got the syntax right from memory" [current
Portage svn] (something similar to):

- ---- sets.conf ----
[slot-4.1]
class=dbapi.VariableSet
variable=SLOT
include=4.1

[kdebase]
class=files.StaticFileSet
filename=kdebase

[kdebase-4.1]
class=base.DummyPackageSet
extend=kdebase
intersect=slot-4.1
- ---- sets.conf ----

Being able to take advantage of use deps for packages would be a bonus:
kde? (
x11-libs/compizconfig-backend-kconfig
x11-wm/compiz[kde]
)


These type of sets cover what I need / would like to have at the moment.
How would I like to use them? I would like to have the sets defined in
the tree as "base" sets that users can "tweak" to their needs. So they
should be able to use something similar to package.use (package.use
itself?) to add desired conditional deps such as "@compiz-fusion
- -emerald -gnome kde unsupported". With the sets operators being defined
by genone for Portage[1] '-', '/' users should also be able to create
sets with a list of packages they don't want to install, so if someone
wouldn't want to install kppp with @kdenetwork, they could create a
@kdenetwork-unwanted set with kppp and run "emerge -av
@kdenetwork-@kdenetwork-unwanted". It would be really helpful if we
could have a "package.mask" like structure that allowed users to "mask"
deps from sets (does / could package.mask be used this way?) so that one
wouldn't be forced to run "emerge -av @kdenetwork-@kdenetwork-unwanted"
every time. Running "emerge -av @kdenetwork/@installed" to reinstall
only installed deps or "emerge -uDav @kdenetwork/@installed" to update
the existing deps are also interesting ideas. Perhaps we should start
doing "emerge -uDav @world/@installed".

Marius suggests the following for the subtraction issue (the same
warning as above):
- ---- sets.conf ----
# assuming @kdenetwork is already defined in a higher level sets.conf

[kdenetwork-ignore]
class=base.DummyPackageSet
packages=kde-extra/i-dont-want-this

[kdenetwork]
remove=kdenetwork-ignore
- ---- sets.conf ----

So this is what I would like to see with sets. Am I crazy? Is it
possible to do any of this? Anyone has some other needs?

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE

[1] -
http://planet.gentoo.org/developers/genone/2008/09/29/more_extensions_to_package_set_support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjm5yEACgkQcAWygvVEyAL6YwCZAaLiyKm8sU ySAcgIgBdPDStT
ZcQAn3+FGPlnmlxKPdKOkWQizs//vuKP
=They
-----END PGP SIGNATURE-----
 
Old 10-04-2008, 06:07 AM
Marius Mauch
 
Default PROPERTIES=set for meta-packages that should behave like package sets (revised)

On Sat, 04 Oct 2008 03:46:41 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:

> It would also be important to have versioned sets (depending on a
> slot, for example). Marius Mauch (genone) suggested a very
> interesting way to solve this by using a set config file (portage
> specific) that, as he stated, "should work if I got the syntax right
> from memory" [current Portage svn] (something similar to):
>
> - ---- sets.conf ----
> [slot-4.1]
> class=dbapi.VariableSet
> variable=SLOT
> include=4.1
>
> [kdebase]
> class=files.StaticFileSet
> filename=kdebase
>
> [kdebase-4.1]
> class=base.DummyPackageSet
> extend=kdebase
> intersect=slot-4.1

Small correction: The example above doesn't actually work as intended,
as the VariableSet handler only operates on installed packages, so
@kdebase-4.1 would actually contain atoms that are
- listed in @kdebase
- have SLOT=4.1
- are already installed

> - ---- sets.conf ----
>
> Being able to take advantage of use deps for packages would be a
> bonus: kde? (
> x11-libs/compizconfig-backend-kconfig
> x11-wm/compiz[kde]
> )

Basic use deps are supported (those that don't expand to use
conditionals), use conditionals are not, and probably won't be for
various reasons.

> It would be really helpful if we could have a "package.mask" like
> structure that allowed users to "mask" deps from sets (does / could
> package.mask be used this way?)

Well, portage has a set handler for wrapping /etc/portage/package.*
files in sets, which in combination with the substraction operator /the
"remove" option in sets.conf can be used for this purpose.

> Perhaps we should start doing "emerge -uDav @world/@installed".

What would be the point of that?

> So this is what I would like to see with sets. Am I crazy? Is it
> possible to do any of this? Anyone has some other needs?

Well, pretty much all what you want is possible with current portage
codebase (only available via svn, not released yet), except for use
conditionals, and the issue about VariableSet mentioned above, but
that's fixable in several ways. Mind that details of the examples above
might change over time as that stuff is just a few days old.

Using that stuff in the tree however is a completely different issue,
as the current sets.conf format will likely never be supported by other
package managers than portage (as it's somewhat tied to the portage
API).

Marius
 

Thread Tools




All times are GMT. The time now is 04:45 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org