As an example given the django-9999 ebuild, to match a developer's environment I need to checkout R12120 from trunk. Installing Django manually is not an option due to package management reasons. But there is also no ebuild in portage for 1.2 beta versions.
So I did the following:
ESVN_OPTIONS="-r12120" emerge -1a django
Which installed the required revision from svn. But this is cumbersome in a way. Is there some way to define this statically per ebuild, eg something like:
DJANGO_SVN_REV="12120"
in make.conf. This would be much cleaner in my eyes.
Because next time I need to rebuild django for whatever reason, I need to remember: "Oh I wanted this to stick to a specific revision" and next question will be "err, f&!#$?%, what was it again?"
What's the best way to go here?
Keep in mind:
- Manually installing packages without package manager knowledge is no option
- Working around with manual emerge variable prefixing is no option
- Setting up a /etc/portage/package.env would be a way to go (as described here) but that seems pretty unsupported and kludgy to me and thus unpreferable
- Modifying make.conf would be a way to go
- Keeping the ebuild in an overlay would be an option
I'm not completely against using
package.env. If you understand and document it within your environment it can be a useful method to apply subtle changes with ebuild hooks whilst still tracking stable ebuilds.I don't think it's an appropriate way to fix the revision of a
-9999ebuild though - according to the "principle of least astonishment". Nor doesmake.confseem a very obvious place to fix package versions.A cleaner approach would be to roll your own ebuild with Layman. If you name it
django-1.2_pre12120then it should be more obvious what it's doing and gives you an easy exit route once Django 1.2 is released and stabilised in Portage.