Here is an issue that is currently being faced by the java project that
I would like to bring to the attention of everyone. I have already
discussed this will devs from all pm's.
Intro:
Within the java project we have 2 overlays. java-overlay and
java-experimental. java-overlay is mean't to be a "stable" overlay, is
available through layman while java-experimental is the opposite. We
attempt to not add packages to gentoo unless they are a dependency or an
application to help with maintainability. We allow newbies access to
java-experimental and there are a number of packages that are difficult
to support so are still very much experimental.
The way we are currently using the overlays results in a hierachy of
gentoo > java-overlay > java-experimental. Where
packages/eclasses/profiles can be inherited from the previous repository.
Problem:
Repoman currently only checks the current repository/overlay and gentoo.
This is a problem for java-experimental.
These are the following problems:-
1) repoman does not find eclasses used to by java-experimental ebuilds
that are located in java-overlay. see [1] for error. Maintaining the
eclass in multiple locations _is not a solution_.(zmedico is expecting
to add repository support at some point with support for specifying
ECLASSDIRS. So this issue may be resolved).
2) repoman does not find packages used to by java-experimental ebuilds
that are located in java-overlay.
Now this might be a result of the package not existing within gentoo or
as a result of a particular version/slot being available within
java-overlay. Now zmedico suggested that the use of repository deps (
aka ::java-overlay ) could be the solution. I would rather this not be
the solution as packages shouldn't need to be edited to more them
between overlays. Also the dependency specified could be moved into gentoo.
Possible Solution:
Now im going to shoot myself in the foot here by mentioning the
unmentionable.
( -->> ) paludis ( <<-- ) currently has support for specifying an
overlays parent(s) (master_repository) within an overlays
metadata/layout.conf file. Now i'm not suggesting that paludis's
implementation is the correct one, but I believe the concept is solid.
By specifying an overlays parent repositories would allow (at least):
1) emerge to error if that repository/overlay is not configured.; and
2) repoman to locate packages by checking the current overlay, gentoo as
well as the parents specified within an "overlay metadata file"
Possible Solution:
Merging java-overlay and java-experimental. From my perspective this
isn't a good one as we loss most of the benefits of java-experimental.
Discussion:
Do you support the "overlay metadata file" concept?
Are there any other possible solutions?
Is there anything stopping this from being implemented? another EAPI?
profile EAPI?
Is there anything else that would benefit from an "overlay metadata
file"? Default conf variables e.g ECLASSDIRS.
Any other comments?
Thanks
ali_bush
Alistair Bush
Gentoo Linux Developer
[1]
* ERROR: dev-java/commons-jelly-tags-util-1.0 failed.
* Call stack:
* ebuild.sh, line 1881: Called source
'/home/alistair/gentoo/overlays/java-experimental/dev-java/commons-jelly-tags-util/commons-jelly-tags-util-1.0.ebuild'
* commons-jelly-tags-util-1.0.ebuild, line 7: Called inherit
'commons-jelly-tags-2'
* ebuild.sh, line 1238: Called qa_source
'/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass'
* ebuild.sh, line 37: Called source
'/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass'
* commons-jelly-tags-2.eclass, line 30: Called inherit
'java-pkg-2' 'java-ant-2' 'java-maven-2'
* ebuild.sh, line 1215: Called die
* The specific snippet of code:
* [ ! -e "$location" ] && die "${1}.eclass could not be
found by inherit()"
* The die message:
* java-maven-2.eclass could not be found by inherit()
*
* If you need support, post the topmost build error, and the call stack
if relevant.
* This ebuild used the following eclasses from overlays:
*
/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass
*
/home/alistair/gentoo/overlays/java-experimental/eclass/java-pkg-2.eclass
*
/home/alistair/gentoo/overlays/java-experimental/eclass/java-utils-2.eclass
* This ebuild is from an overlay:
'/home/alistair/gentoo/overlays/java-experimental/'
[2]
dev-java/glazedlists/glazedlists-1.7.0-r2.ebuild:
~amd64(default/linux/amd64/2008.0/server) ['dev-java/swingx']
dev-java/swingx is located in java-overlay.
