sets remove support replacement?
 

I noticed that sets remove support wasn't working any longer, when
depclean all of a sudden decided most of kde4 was no longer in world! A
bug search reveals

http://bugs.gentoo.org/show_bug.cgi?id=291414

which references

http://bugs.gentoo.org/show_bug.cgi?id=253802#c7

which says that's deliberate.

OK, both KDE and I knew it wasn't set in stone back when we began using
it, but now I'm stuck looking for a workable replacement. Here's my
usage scenario:

I want to install /some/ of the packages from the sets in the kde-testing
overlay, but not all of them. Furthermore, as upgrades come and go, I
want to be notified of any /new/ additions to the sets, so I can choose
whether I want them or not.

What I was doing to now was using the sets in kde-testing as a base, with
a second set configured as a remove set from the first. This way, I got
the packages I wanted from the current configuration, and as new packages
were added, they showed up as new (as opposed to upgrade), and I could
grep the kde-testing sets to see where they were coming from, do an
esearch or google on the package to see what it was, and decide whether
to let it install, or add it to my remove set as appropriate.

Now remove sets don't work. What are the options? The most direct is to
simply create my own set listing everything I want, but that won't
account for anything added to the sets as they appear upstream over
time. What to do about that?

I suppose I could create an update script that diffs the new kde-testing
set against a copy I stashed somewhere, thus showing me the differences,
and that I could then update my own set and the stashed copy of the
upstream set accordingly. Is that the best option under the
circumstances, or does portage provide some other replacement for the
functionality I just lost in that regard, with the loss of remove set
functionality?

Anyway, looking forward to when the sets feature is in stable portage, as
it's sure nice to have... even if it /was/ nicer before this feature
disappeared... =:^s But it's on the way to better, I know that. =:^)

--
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

sets remove support replacement?
 

Duncan wrote:
> Now remove sets don't work. What are the options? The most direct is to
> simply create my own set listing everything I want, but that won't
> account for anything added to the sets as they appear upstream over
> time. What to do about that?
>
> I suppose I could create an update script that diffs the new kde-testing
> set against a copy I stashed somewhere, thus showing me the differences,
> and that I could then update my own set and the stashed copy of the
> upstream set accordingly. Is that the best option under the
> circumstances, or does portage provide some other replacement for the
> functionality I just lost in that regard, with the loss of remove set
> functionality?

There's no replacement for it yet, so yes, for now that seems like
the best option if you need such fine-grained control.
--
Thanks,
Zac

sets remove support replacement?
 

Zac Medico posted on Wed, 18 Nov 2009 23:36:28 -0800 as excerpted:

> There's no replacement for it yet, so yes, for now that seems like the
> best option if you need such fine-grained control.

Thanks. Done. =:^)

--
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