Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 161025 - eutils.eclass Enhance CD_ROOT variable.
Summary: eutils.eclass Enhance CD_ROOT variable.
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Games (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Games
Depends on:
Reported: 2007-01-08 22:57 UTC by Olliver Schinagl
Modified: 2017-04-05 20:59 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Olliver Schinagl 2007-01-08 22:57:47 UTC
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.
Comment 1 Chris Gianelloni (RETIRED) gentoo-dev 2007-01-10 00:42:12 UTC
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.
Comment 2 Olliver Schinagl 2007-01-10 01:03:15 UTC
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.
Comment 3 Paul Bredbury 2007-01-10 17:05:57 UTC
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
Comment 4 Olliver Schinagl 2007-01-10 17:16:28 UTC
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.
Comment 5 Paul Bredbury 2007-01-10 17:28:28 UTC
(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 :-(
Comment 6 Olliver Schinagl 2007-01-10 18:22:05 UTC
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? :)
Comment 7 Chris Gianelloni (RETIRED) gentoo-dev 2007-01-11 15:11:23 UTC
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.
Comment 8 Olliver Schinagl 2007-01-11 15:17:51 UTC
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 :)
Comment 9 James Le Cuirot gentoo-dev 2017-04-05 20:59:40 UTC
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.