Re: [gentoo-dev] QA Overlay Layout support.

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alistair Bush wrote:
> 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.

Sorry for taking so long to reply to the mail.
The KDE team had followed the Java example, but has since been forced to
merge the 2 overlays together, exactly because of the issues discussed
in this mail.

> 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.

Agreed.

> 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.

Repository deps would be very helpful. They could be used to "link"
packages in an overlay to packages in another overlay.

> 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.

I agree, but that's what we (KDE) were forced to do.

> 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.
>

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmrE9wACgkQcAWygvVEyAIasQCdHKcpiwj1yXJvAp58Jn2he5pG
7acAoJyx8H2gDEC+kBuwVfecjCQBwJfL
=7OBb
-----END PGP SIGNATURE-----