Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
On Sat, 04 Oct 2008 03:46:41 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] 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
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets (revised)
On Fri, 03 Oct 2008 00:10:56 -0700 Zac Medico [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] 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 [EMAIL PROTECTED] 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-
Re: [gentoo-dev] [RFC] 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 @[EMAIL PROTECTED]. 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 @[EMAIL PROTECTED] 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 iEYEARECAAYFAkjm5yEACgkQcAWygvVEyAL6YwCZAaLiyKm8sUySAcgIgBdPDStT ZcQAn3+FGPlnmlxKPdKOkWQizs//vuKP =They -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
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
-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-
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-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
-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 @[EMAIL PROTECTED] 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
-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 @[EMAIL PROTECTED] 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-
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: On Sat, 27 Sep 2008 17:21:18 -0700 Zac Medico [EMAIL PROTECTED] 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
On Sun, 28 Sep 2008 10:42:39 -0700 Zac Medico [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Sat, 27 Sep 2008 17:21:18 -0700 Zac Medico [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 28 Sep 2008 10:42:39 -0700 Zac Medico [EMAIL PROTECTED] 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sat, 27 Sep 2008 17:21:18 -0700 Zac Medico [EMAIL PROTECTED] 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
On Sun, 28 Sep 2008 13:53:12 -0700 Zac Medico [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 28 Sep 2008 13:53:12 -0700 Zac Medico [EMAIL PROTECTED] 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
On Sun, 28 Sep 2008 15:11:42 -0700 Zac Medico [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 28 Sep 2008 15:11:42 -0700 Zac Medico [EMAIL PROTECTED] 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
On Sun, 28 Sep 2008 15:56:27 -0700 Zac Medico [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 28 Sep 2008 15:56:27 -0700 Zac Medico [EMAIL PROTECTED] 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-
