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