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