1 |
Alec Warner <antarus@g.o> posted |
2 |
b41005390905312058p314e6e1bnda50488d56ba0800@××××××××××.com, excerpted |
3 |
below, on Sun, 31 May 2009 20:58:27 -0700: |
4 |
|
5 |
> On Sun, May 31, 2009 at 4:21 AM, Marijn Schouten (hkBst) |
6 |
> <hkBst@g.o> wrote: |
7 |
>> |
8 |
>> I think [trialware install] is an interesting use-case. It would be |
9 |
>> very simple to handle it by introducing an additional file that the |
10 |
>> package manager would use to record the packages that are installed on |
11 |
>> trial-basis. This would make it possible to include these packages in |
12 |
>> dep-calculations, while still distinguishing them from packages that |
13 |
>> are in @world. Of course you can also fake it by creating a local |
14 |
>> virtual/trialware package (or possibly a @trialware group) of which you |
15 |
>> edit the deps, but this would be less convenient. For my personal |
16 |
>> workflow using -1 for trials is working well enough, atm. |
17 |
> |
18 |
> Why is a custom set less convenient? |
19 |
|
20 |
I read it as... |
21 |
|
22 |
>> [manually] creating a local virtual/trialware package (or possibly |
23 |
>> a @trialware group) of which you |
24 |
>> edit the deps, but this would be less convenient. |
25 |
|
26 |
The key word being the one I supplied, "manually". |
27 |
|
28 |
IOW, individuals could manually create the functionality currently, but |
29 |
this would be less convenient than if portage shipped with the trialware |
30 |
group functionality, no matter how it was implemented. |
31 |
|
32 |
IOW, manual creation isn't as convenient as having it a normal part of |
33 |
portage would be. |
34 |
|
35 |
-- |
36 |
Duncan - List replies preferred. No HTML msgs. |
37 |
"Every nonfree program has a lord, a master -- |
38 |
and if you use the program, he is your master." Richard Stallman |