On Wed, Jun 3, 2009 at 4:05 AM, Marijn Schouten (hkBst)<hk...@gentoo.org> wrote:
> Hash: SHA1
> Alec Warner wrote:
>> On Sun, May 31, 2009 at 4:21 AM, Marijn Schouten (hkBst)
>> <hk...@gentoo.org> wrote:
>> Duncan wrote:
>>>>> Patrick Börjesson <psychoti...@lavabit.com> posted
>>>>> 20090529201741.gb11...@nexon.nexus, excerpted below, on  Fri, 29 May 2009
>>>>> 22:17:41 +0200:
>>>>>> Why exactly would you want to use --oneshot for a "leaf package" that is
>>>>>> not depended on by any other package in the world set? If spam IS
>>>>>> depended on by any other package (recursively) in the world set, it will
>>>>>> be pulled in by --complete-graph, but that's not the case here if i
>>>>>> understand it correctly, thus it's a package that you explicitly wanted
>>>>>> installed, thus it belongs in the world set, and you should thus not use
>>>>>> --oneshot for it.
>>>>> I use -1 by default, here (via scriptlet), mainly so I don't have to
>>>>> worry about cluttering up my world file while emerging individual
>>>>> packages, just as I always use -NuD with my @system and @world runs.
>>>>> But for leaf packages, it serves as a sort of test install as well.
>>>>> Since I always do revdep-rebuild -p and emerge --depclean -p after every
>>>>> update (typically 2-3 times a week), then rebuild and clean as I need to,
>>>>> keeping the "trial merges" on the depclean list for a few days keeps me
>>>>> aware of them.  If I know it's something I want to keep, I run a
>>>>> different scriptlet without the -1, but that's not often once a system is
>>>>> up and running with the normal working set merged.  Meanwhile, I
>>>>> ultimately either emerge -C (or let depclean handle it) the "trialware",
>>>>> or emerge --noreplace, thus adding it to world.
>>>>> But experimental installs and their deps typically sit in the --depclean
>>>>> list for anything from a few minutes to a few days, until I decide
>>>>> whether I want to keep or remove them.
>>>>> If he was testing how the switches under discussion here worked and has a
>>>>> similar policy, I could easily see him using -1 by habit, even if he
>>>>> didn't explicitly reason that it was a test and therefore something he
>>>>> didn't want in @world.
>> I think this is an interesting use-case. It would be very simple to handle 
>> it by
>> introducing an additional file that the package manager would use to record 
>> the
>> packages that are installed on trial-basis. This would make it possible to
>> include these packages in dep-calculations, while still distinguishing them 
>> from
>> packages that are in @world. Of course you can also fake it by creating a 
>> local
>> virtual/trialware package (or possibly a @trialware group) of which you edit 
>> the
>> deps, but this would be less convenient. For my personal workflow using -1 
>> for
>> trials is working well enough, atm.
>>> Why is a custom set less convenient?
> Well, instead of "emerge --trialware package" you would first have to edit 
> your
> @trialware set and then "emerge @trialware". The same goes for when you want 
> to
> remove some trialware.
> Perhaps some generalization of --trialware along the lines of
> - --add-to-set=trialware could be fleshed out as a useful extension of 
> portage.

I like sandwiches too, so perhaps we can have a
--sudo_make_me_a_sandwich option to emerge?

But seriously, this is linux.  If users want do deal with "a set of
packages that are like trialware" then they should use the sets
functionality that emerge already ships with.  emerge
--add-to-set=blah might be passable but IMSHO emerge has plenty of
options already and users can easy write their own wrappers for this
kind of thing.  Emerge doesn't need every tiny feature built into it.

> Marijn
> - --
> If you cannot read my mind, then listen to what I say.
> Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
> <http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
> Version: GnuPG v2.0.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> vvMAoMMeLUxnM2i8fpJhClxbsIqwMf3Z

Reply via email to