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@g.o> posted 48E00B9B.3060600@g.o,
> 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-----