Re: [gentoo-dev] Sets vs Meta ebuilds

["William L. Thomson Jr." <wlt-ml@o-sinc.com>]

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

On Fri, 7 Jul 2017 13:31:52 -0400
NP-Hardass <NP-Hardass@gentoo.org> wrote:

> On 07/07/2017 01:05 PM, William L. Thomson Jr. wrote:
> > On Fri, 7 Jul 2017 12:48:04 -0400
> > NP-Hardass <NP-Hardass@gentoo.org> wrote:  
> >>
> Yeah, but I'm not wild about the prospect of handling some packages
> via one method, and others via another.  Could you imagine if half of
> your @system packages were broken up into subsets, and half were left
> as is? The lack of uniformity would unnecessarily complicate things
> IMO.

This is meant to be used at higher levels. Say you want a set of Gnome
packages on KDE, as an example. Or some set of packages of your own.

> Then why are we in a topic comparing metas and sets? :P  Sounds like
> the best thing is to change this whole topic into an RFC for
> profile-enabled sets and file a bug report feature requesting it
> after getting feedback.

Because they each have their use. But seems sets may be under-used.
This topic is more of a RFC and I may file a bug/feature request after.
Granted the topic/process might not have been ideal, but doing just
what you mentioned.
 
> This is two-tiered in both cases anyway, no?

No

> Meta:
> # Remove meta
> emerge --depclean meta
> # Remove all packages in the meta and their pulled in deps
> emerge --depclean
> Set:
> # Remove set
> emerge --depclean @set

That removes the set and any packages brought in, not just the set
packages. You do not need the --depclean to remove a package set.

> # clean up all deps pulled in from the set
> emerge --depclean

Same thing as previous command. Adding --depclean to sets gives you
that. As there is no deps on a set that are not in that set.

Either way you cannot re-emerge packages in a meta. Like rebuilding all
of those. At least not easily to my knowledge.

> > 
> > Sets do have their uses. I think they are not used much for a
> > variety of reasons, but likely could be used more.
> >   
> 
> Sure, but when the thread is "Sets vs Metas" it makes it hard to
> simply "make a case for using one more than currently" since instead,
> you are inviting a comparison argument, which, as I've said, I think
> fails to convince.  Like I said, if your goal is simply to propose
> enabling further use of sets, let's work on that, rather than get
> distracted with a whole separate issue.

They should be compared. Given their differences there is a time and
place to use either. Creating a profile for select packages is
overkill. I think even a meta package of the same is also over kill.
Which does not give you all the same abilities.

I see sets as being very useful in profiles. Meta packages not so much.
That depends on the profile and packages. I see lots of uses for sets
and little use of meta packages. My use of meta packages would be to
get around limitations of ability to use sets. Which is not ideal IMHO.

-- 
William L. Thomson Jr.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]