1 |
On Tue, 18 Apr 2017 07:51:58 +0200 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> >>>>> On Mon, 17 Apr 2017, James Le Cuirot wrote: |
5 |
> |
6 |
> > If you've been wondering why I've been quiet of late (you have, |
7 |
> > right?!) then this is partly why. I'm not sure why I spent so long |
8 |
> > on an eclass that hardly anyone uses but it's utilised by many of my |
9 |
> > old favourite games. |
10 |
> |
11 |
> Wouldn't this be a good time to rethink the whole concept? By all our |
12 |
> standards, ebuilds shouldn't be interactive. AFAICS, cdrom.eclass is |
13 |
> the last remnant in the tree using PROPERTIES="interactive". |
14 |
|
15 |
mgorny makes good points, it is indeed not quite that simple. |
16 |
|
17 |
I didn't actually notice the --accept-properties=-interactive feature |
18 |
until just now, that's pretty cool. |
19 |
|
20 |
Although I agree it should be avoided, there may be other uses for it |
21 |
in future. I'd still like to go ahead with my lgogdownloader plan |
22 |
(probably via a new src_fetch) and that may need it for entering |
23 |
credentials on rare occasions though there are other possibilities. |
24 |
|
25 |
> Maybe the eclass could be replaced by a utility that extracts the ISO |
26 |
> image and places it into DISTDIR, so that ebuilds could use regular |
27 |
> non-interactive unpacking? The additional disk space used shouldn't be |
28 |
> an argument any more with today's large disks. |
29 |
|
30 |
Don't assume everyone has such huge disks. ;) My main system isn't bad |
31 |
but that doesn't mean I want to waste the space on something like this. |
32 |
Many have written optical media off but I still have two big flight |
33 |
cases full of discs of various kinds nearby. |
34 |
|
35 |
No one is forced to use this stuff and it is possible to use it in a |
36 |
non-interactive manner similar to how you suggest. You can copy the |
37 |
files from the disc(s) and point CD_ROOT to this location in a |
38 |
per-package env file. |
39 |
|
40 |
-- |
41 |
James Le Cuirot (chewi) |
42 |
Gentoo Linux Developer |