El sáb, 16-06-2012 a las 22:07 -0500, Dale escribió:
> Duncan wrote:
> >
> > Looking at the broader picture, the problem of extraneous packages in the
> > world file has always concerned me. If it were to be done over again,
> > and I think Zac would likely agree, emerge would use --oneshot by
> > default, so as not to contaminate the world file unnecessarily. Then
> > there'd be a different option (say -2) to add the package to the world
> > file if that's what was actually intended.
> >
> > That's actually how I have my emerge front-end scriptlets/aliases setup
> > here. -1 is the default; if I want it in the world file I use the *2
> > script variant, which omits the -1.
> >
> > But of course changing behavior in mid-stream doesn't work so well, so
> > emerge continues to stick stuff in the world file by default.
> >
>
> I added -1 to my make.conf a long time ago. Whenever I emerge something
> and want it in the world file, just use the --select option. If I
> already emerged something but then want to add it to the world file,
> just add the -n option too. That keeps the world file clean and I can
> test things before adding anything to the world file.
>
> Dale
>
> :-) :-)
>

The problem is that this wouldn't solve the first issue because people
would still need to emerge extra packages with "--select" option if they
don't want to see them going away on next depclean round even if package
that needed them is still installed

El sáb, 16-06-2012 a las 22:10 +0200, Peter Stuge escribió:
> Pacho Ramos wrote:
> > > I guess the point is that it is not really a dependency.
> >
> > No, it's a dependency only when you want ppp support working,
>
> Logically, but not technically.
>
> I like this separation; the package manager takes care of technical
> requirements, and I get to take care of the logical requirements.
>
>
> > > I dunno if a USE flag is much better? Both require the user to inform
> > > herself in the same way ("when do I need USE=ppp for bluez" vs. "when
> > > do I need to emerge ppp")
> >
> > It's much easier to widely set "ppp" USE in make.conf to be sure ppp
> > support works for all things in my system that needing to rebuild
> > affected package to see elog message telling me that I need to manually
> > emerge some other package
>
> My point is that when you know that you need ppp (and how could you
> set USE=ppp otherwise) then it is about equally easy to emerge ppp
> as it is to set USE=ppp.

But that point is valid with this exact example because, in this case,
it's really intuitive to do so, but in other cases in the tree, there is
not such good liaison between USE flag name and needed package

>
>
> > > > people end up with a lot of packages they needed to manually
> > > > emerge some year but that they problem no longer need at all.
> > >
> > > Disk is pretty cheap. If the package is never being used and the user
> > > doesn't care to remove it then the package doesn't do any harm IMO,
> > > and as mentioned I think it's difficult for the package manager to
> > > know what the user has installed on the system but no longer needs..
> >
> > What kind of argument is "disk is pretty cheap".
>
> Please read the rest of what I wrote too.
>
>
> > I still administrate a laptop with a 250GB of disk space, and that
> > space cannot be as large if you have a lot of files at home.
>
> My primary system had 8GB storage until a few years ago when flash
> prices went down. I was motivated to keep my system clean. If one is
> space constrained then I think one naturally pays more attention to
> keeping world small. Disk is still cheap. If it is a problem for me
> that I have unneeded packages installed, *then* I will start looking
> at cleaning up. Until then, there's no problem.
>
>
> > Also, you are missing that having unneeded packages in world file
> > will also cause them to be updated on every system updated, with
> > the time it takes for compile.
>
> I'm not missing, but I'm saying that it is merely the effect of not
> managing world very actively.
>
> I think it's difficult to impossible for a package manager to
> reliably determine logical requirements from what is a model
> (USE flags) of technical requirements (link-time dependencies).
>
>
> //Peter

Well, looks like a solution for this is already implemented in exherbo
and there were also similar solutions proposed in the past, lets see if
we can agree on witch one would be better for us

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 17 Jun 2012 03:35:08 +0200
hasufell <hasufell@gentoo.org> wrote:
> On 06/16/2012 08:14 PM, Ciaran McCreesh wrote:
> > Suggested dependencies were used in the old kdebuilds, and Exherbo
> > makes extensive use of both suggested and recommended dependencies,
> > so there are plenty of examples, spec wording and an implementation
> > already if you want to play.
>
> I don't want to install Exherbo to see an example. Archlinux also has
> a nice implementation about optional dependencies and I don't care
> about that either.
>
> This is about a gentoo specific implementation and I am still not
> clear about how that proposed SDEPEND would look like.
> Are useflags allowed for those too? How do I "activate" it? Via a
> seperate config file in /etc/portage, is it a FEATURE? what what what

Surely being able to use it and play around with it for real is better
than seeing some not very helpful textual examples pasted in... Anyway,
you can probably find the old kdebuilds somewhere, those run on Gentoo.
For that matter, the Paludis ebuild in the overlay makes use of
suggestions, although it's only for one small set of things.

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk/dyD0ACgkQ96zL6DUtXhFrUgCgkxzRAgqaDf6Al1/Zp9n7wRJL
pRYAoOBw7143Mch81VvBVsK3Us0FilRM
=JGNo
-----END PGP SIGNATURE-----

On 06/16/2012 02:56 PM, Duncan wrote:
> Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets.
> Since I've been working with kde4 since it was overlay-only and sets-
> only, no meta-packages, I've been using sets for quite awhile and it's
> now entirely integrated into how I work with portage.
>
> When I setup my netbook on gentoo, I wanted most of the same setup as on
> my main machine, but with some differences, so I had to go thru the main
> machine's world file and pick and choose what I needed.
>
> What I quickly realized is that my kde packages were already nicely
> categorized into sets, so all I really needed to do was split up the rest
> of the world file into a bunch of other sets, by category. So for
> instance:
>
> $>>cat /etc/portage/sets/jed.dev
> dev-util/ccache
> dev-util/desktop-file-utils
> dev-vcs/git
> sys-devel/bin86
> sys-devel/gcc
> sys-devel/gdb
>
>
> I have 24 such sets including my (customized) kde sets. All packages
> formerly listed in the world file are found in these sets, instead, and
> of course the sets are in turn listed in /var/lib/portage/world_sets.
>
> My world file is normally entirely empty, tho I do use it occasionally
> for packages I haven't decided whether I want to keep or not, but want to
> protect from --depclean, which I run after each update. So my world file
> serves as a kind of package purgatory, until I decide whether it's going
> to be a part of my normal system, or removed.
>
> The sets, meanwhile, break the former world file down into much more
> manageable categorized chunks, each of which is short enough and
> categorized specifically enough that if a package is no longer needed, it
> immediately sticks out like a sore thumb, as it's not lost among the
> noise of hundreds of "twisty packages, all different". =:^)
>
>
> While not a direct solution to the problem at hand, proper use of sets
> WILL and DOES dramatically ease gentoo world-package administration,
> going a long way toward eliminating crufty world lists simply by allowing
> them to be cut into nice little chunks that can be categorized in ways
> that make sense for an individual site, so the cruft sticks out like the
> sore thumb it can really be, and is thus easily found and removed.
>
>
> Meanwhile, another bonus of sets is the extra protection it gives you if
> you try to emerge -C something in a sets file (as opposed to the world
> file itself). =:^) Seeing that warning that the package is in a set and
> can't be directly unmerged is rather like seeing the warning that it's in
> @system, except that user sets are easier to directly manage, and it has
> saved my butt a couple times when I was really too sleepy to be adminning
> the system in the first place. But it's easy enough to remove (or
> comment) that line from the set, if removal is really intended, and
> that's what would ultimately need to be done anyway, to prevent it
> getting remerged.
>
>
> Unfortunately, it has begun to look like sets are where baselayout2 and
> openrc were for many years, "forever coming, never getting here", at
> least for stable or even unmasked into ~arch. =:^(

Support for /etc/portage/sets is included in portage-2.1.11:

https://bugs.gentoo.org/show_bug.cgi?id=384061
--
Thanks,
Zac

Zac Medico posted on Sat, 23 Jun 2012 16:30:53 -0700 as excerpted:

> On 06/16/2012 02:56 PM, Duncan wrote:
>> Meanwhile, one coming solution to this, in portage 2.2 anyway, is sets.

>> Unfortunately, it has begun to look like sets are where baselayout2 and
>> openrc were for many years, "forever coming, never getting here", at
>> least for stable or even unmasked into ~arch. =:^(
>
> Support for /etc/portage/sets is included in portage-2.1.11:
>
> https://bugs.gentoo.org/show_bug.cgi?id=384061


Hallelujah! I see from the bug comments that it just landed, too.
Thanks!


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