[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Sat, 04 Oct 2008 10:17:05 -0700 Zac Medico [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Thu, 02 Oct 2008 02:51:53 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] 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-metafoo 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 signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Sat, 4 Oct 2008 00:05:53 -0600 Ryan Hill [EMAIL PROTECTED] wrote: On Thu, 02 Oct 2008 02:51:53 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-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-
Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
On Wed, 01 Oct 2008 09:37:25 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: On Mon, 29 Sep 2008 22:31:46 -0700 Zac Medico [EMAIL PROTECTED] 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-metafoo 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. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: On Mon, 29 Sep 2008 22:31:46 -0700 Zac Medico [EMAIL PROTECTED] 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-metafoo 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: Ryan Hill wrote: On Mon, 29 Sep 2008 22:31:46 -0700 Zac Medico [EMAIL PROTECTED] 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-metafoo 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
On Mon, 29 Sep 2008 22:31:46 -0700 Zac Medico [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: Zac Medico [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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
Zac Medico [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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
[gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
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
-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: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Zac Medico [EMAIL PROTECTED] posted [EMAIL PROTECTED], 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
