On 07/07/2017 01:05 PM, William L. Thomson Jr. wrote: > On Fri, 7 Jul 2017 12:48:04 -0400 > NP-Hardass <np-hard...@gentoo.org> wrote: >> >> There is actually a huge functional difference between the two that >> you are missing here. A meta package defines its dependencies in full >> dependency syntax. This means you can specify versions, USE flag >> dependencies, make packages dependent on USE flags, etc. A package >> set is just a list of packages (potentially constrained by version. >> TTBOMK, there is no inclusion of any USE flag functionality in sets. >> Additionally, let's say you have a more complicated dependency like >> || ( A B ), I don't think there is a way to describe that in a >> package set at all. > > All valid points, but there maybe times when such is not needed. > > You cannot really do any of that easily via a profile either. You just > have packages file in a profile. You can use the other stuff, but I am > talking about sets. Just as packages are listed in a packages file in a > profile. Being able to list a package set, vs those same packages. > There is no difference there. >
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. >> I'm not sure I see the merit in pushing for package sets in the bulk >> of cases for this reason. Maybe there is some scenario where package >> sets are a better option, but you haven't enumerated what that might >> be (and I'm not really interested in brainstorming until I come up >> with one, so I'll wait for one frmo someone else) > > Not sure I need to show a case example of where sets are better than > meta packages. Its more I want to use sets and I would like to be able > to include those package sets in a profile. > 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. >> Of course, my sets knowledge is a little limited compared to some >> people, so if something I've said about package sets is incorrect, >> please feel free to correct it. > > You cannot remove all packages ( short of dep clean ) or re-emerge all > packages from a meta ebuild easily. You can from a set. This is two-tiered in both cases anyway, 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 # clean up all deps pulled in from the set emerge --depclean > > 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. -- NP-Hardass
signature.asc
Description: OpenPGP digital signature
