From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-portage-dev+bounces-2459-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1NAYfp-0000w3-9z
for garchives@archives.gentoo.org; Wed, 18 Nov 2009 00:45:29 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id E9F2DE0E7F
for <garchives@archives.gentoo.org>; Wed, 18 Nov 2009 00:45:28 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id D35EFE0B4E
for <gentoo-portage-dev@lists.gentoo.org>; Tue, 17 Nov 2009 22:24:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 79D1167A32
for <gentoo-portage-dev@lists.gentoo.org>; Tue, 17 Nov 2009 22:24:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 required=5.5 tests=[AWL=0.048,
BAYES_00=-2.599]
Received: from smtp.gentoo.org ([127.0.0.1])
by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mmcEmVcHz2eb for <gentoo-portage-dev@lists.gentoo.org>;
Tue, 17 Nov 2009 22:24:19 +0000 (UTC)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTP id B2D6767A05
for <gentoo-portage-dev@gentoo.org>; Tue, 17 Nov 2009 22:24:19 +0000 (UTC)
Received: from list by lo.gmane.org with local (Exim 4.50)
id 1NAWT9-0007WT-KP
for gentoo-portage-dev@gentoo.org; Tue, 17 Nov 2009 23:24:15 +0100
Received: from ip68-231-21-207.ph.ph.cox.net ([68.231.21.207])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-portage-dev@gentoo.org>; Tue, 17 Nov 2009 23:24:15 +0100
Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-portage-dev@gentoo.org>; Tue, 17 Nov 2009 23:24:15 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-portage-dev@lists.gentoo.org
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-portage-dev] sets remove support replacement?
Date: Tue, 17 Nov 2009 22:23:53 +0000 (UTC)
Message-ID: <pan.2009.11.17.22.23.53@cox.net>
Precedence: bulk
List-Post: <mailto:gentoo-portage-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-portage-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-portage-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-portage-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-portage-dev.gentoo.org>
X-BeenThere: gentoo-portage-dev@lists.gentoo.org
Reply-to: gentoo-portage-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: ip68-231-21-207.ph.ph.cox.net
User-Agent: Pan/0.133 (House of Butterflies)
Sender: news <news@ger.gmane.org>
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: f822d360-d525-4007-bf2c-66436e235988
X-Archives-Hash: ebd66c35c5a517193352eb1edbc9291f
I noticed that sets remove support wasn't working any longer, when=20
depclean all of a sudden decided most of kde4 was no longer in world! A=20
bug search reveals=20
http://bugs.gentoo.org/show_bug.cgi?id=3D291414
which references
http://bugs.gentoo.org/show_bug.cgi?id=3D253802#c7
which says that's deliberate.
OK, both KDE and I knew it wasn't set in stone back when we began using=20
it, but now I'm stuck looking for a workable replacement. Here's my=20
usage scenario:
I want to install /some/ of the packages from the sets in the kde-testing=
=20
overlay, but not all of them. Furthermore, as upgrades come and go, I=20
want to be notified of any /new/ additions to the sets, so I can choose=20
whether I want them or not.
What I was doing to now was using the sets in kde-testing as a base, with=
=20
a second set configured as a remove set from the first. This way, I got=20
the packages I wanted from the current configuration, and as new packages=
=20
were added, they showed up as new (as opposed to upgrade), and I could=20
grep the kde-testing sets to see where they were coming from, do an=20
esearch or google on the package to see what it was, and decide whether=20
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=
=20
simply create my own set listing everything I want, but that won't=20
account for anything added to the sets as they appear upstream over=20
time. What to do about that?
I suppose I could create an update script that diffs the new kde-testing=20
set against a copy I stashed somewhere, thus showing me the differences,=20
and that I could then update my own set and the stashed copy of the=20
upstream set accordingly. Is that the best option under the=20
circumstances, or does portage provide some other replacement for the=20
functionality I just lost in that regard, with the loss of remove set=20
functionality?
Anyway, looking forward to when the sets feature is in stable portage, as=
=20
it's sure nice to have... even if it /was/ nicer before this feature=20
disappeared... =3D:^s But it's on the way to better, I know that. =3D:^)
--=20
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