Proposal for having a fixed internal 'CD_ROOT' variable in /etc/make.conf. Let me explain what I mean hereby. Right now, when emerging a package that requires files from a CD, let's say, ut2004 or nwn, it asks you to insert the cd, mount it and point the CD_ROOT variable to it. This is all fine, but some (I agree it's probably not gonna be many) of us have all the CD's, iso's, files stored somewhere for easy access. In my case, I have all game data files/iso's stored in /usr/portage/distfiles/datafiles/) on an nfs share, so I can share the BW and storage of my portage tree amongst all my clients. Though I can just set the CD_ROOT to whatever subdir of that tree for whichever game I want to emerge, it be very handy if an internal check was always made on that tree for the requested gamefiles. Obviously it shouldn't loop back mount isos and mount them somewhere, though even that be handy too :) Users would then only need to copy their files to /usr/portage/datafiles/<ebuild dirname> (is maybe a good spot?) and all games ebuilds always would check that dir if the game files are present. Of course CD_ROOT would always still work. Come to think of it, CD_ROOT could be globally (internaly) defined to the suggested path, but when exported per emerge, overide that path to regain old behavior.
First off, you do NOT have to set CD_ROOT when using actual CD/DVD media, only when using arbitrary locations on the filesystem I actually already thought of this, but my idea was quite a bit different. You would set, for example, ut2004-data_CD_ROOT... The CD-matching functions would check if that existed first, when merging ut2004-data. This would allow for people like you (and me) to store all their CDs on disk permanently and not have to be around for updates.
I don't get that last part you are saying ... (obviously we are assuming that ut2004-data is the non-existent data ebuild that would ONLY pull in the game data :) Well i kept thinking a little about it, but all that really would needed to be done is CD_ROOT to work from /etc/make.conf, and then remove/add <dir/ebuild>name depending on what's being checked. /etc/make.conf: CD_ROOT=/usr/portage/datafiles export CD_ROOT=/media/cdrom then emerge first checks if CD_ROOT is set by the user and if so checks /media/cdrom if not, or it's an empty dir /usr/portage/datafiles/games-fps/ut2004-data/ is being queried followed by /usr/portage/datafiles/ut2004-data/ (I think it's a nice to have both structures) and if that also isn't there, throw an error for a CD not being mounted and setting CD_ROOT manually. This way, you don't have to set the CD_ROOT for each package, like it seems to me you are suggesting, but have one for all packages. Actually, this could be extended well belong game usage, though I don't know of any applications that pulls in data like this. Thinking of packages that need extra data, I belive cedega wants external data, but it's a simple fetch limitation, e.g. if the data is in /usr/portage/distfiles it'll use it. Openttd asks the user to manually copy the data, but could use the same technique and throw the manual copy error instead of setting CD_ROOT, but then we'd be getting into specific package issues.
You can just set up the env (i.e. CD_ROOT or CD_ROOT1,2,3,blah) before the emerge. The number of people who have their CD collection stored on a hard drive is (I reckon) very small. Quake 1 & 2, maybe, but not the DVDs of today. The reason why this idea doesn't work is because *within* a game's CD *emerge*, there needs to be a great deal of flexibility to deal with the CD/DVDs for: * Initial release (bug-ridden, obviously) * Game Of The Year Edition * Game Of The Year Edition (including the Bonus Pack) * Game Of The Year Edition (including the Bonus & Mega Pack) * A totally new release containing all of the above in a new .cab format So it's a pain. Take a look at /usr/portage/games-fps/ut2004-data/ut2004-data-3186-r3.ebuild
and that would still work as is, this won't affect nor change that. This would go into the general games class or higher I suppose.
(In reply to comment #4) > This would go into the general games class or higher I suppose. Which will require a rewrite of cdrom_get_cds() etc. in /usr/portage/eclass/eutils.eclass - which is a horrible piece of code, but *very* difficult to rewrite :-(
so this idea is going to die a silent death, until someone rewrites eutils.class? Is there a bug for that so we could depend this one on that one? :)
Huh? I am totally not following what you mean by other bugs. Anyway, while your idea gives only one variable, mine gives the flexibility. The best solution would probably be a combination of the two. First, you check if ${PN}_CD_ROOT exists, and if it does, you use that. If it doesn't you check for CD_ROOT. If it exists, you check ${CD_ROOT}/${CATEGORY}/${PN}, then ${CD_ROOT}/${PN}, then ${CD_ROOT}. If it doesn't exist, you do the normal detection routines. Of course, this would have to be extended to CD_ROOT_x, also, not just CD_ROOT. That being said, this is *definitely* a *very* low priority, if we even do it at all, so don't expect to see it any time soon. Also, this is not limited to games, so it wouldn't go into any games eclass, but it would be modification of the eutils functions, instead.
With the bug I meant, is there a bug all ready filed asking for a rewrite of eutils class because of it's horrible state. Yeah, I think they combo you offer is of course the best solution. I guess you got to explain it a bit better then I did :)
I think this is effectively rendered obsolete by Portage's package.env feature. You can just set your own CD_ROOT variable(s) in /etc/portage/env/${CATEGORY}/${PN}. That aside, the need for this is obviously much smaller now with optical media on the decline. While I'm still hanging onto my discs, many users seem to make do without optical drives these days.
