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.


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


Reply via email to