| Summary: | How to handle packages having impl-conditional sources? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Current packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | An example ebuild with sol. A | ||
A sounds ok. It might be easier to just have both distfiles in SRC_URI unconditionally. An extra tarball in DISTDIR never hurt anyone. Created attachment 333932 [details]
An example ebuild with sol. A
I followed floppym's advice and didn't make SRC_URI conditional. But to be honest, I dislike my work. I can't think of a sane way to do an ebuild with per-impl conditional sources.
Curiosity: this package has test failures on every python impl but pypy ;).
|
Examples: pycairo, unittest2 They have different source tarballs for py2 & py3; both are maintained and versioned the same. Variant A: ebuild with conditionals SRC_URI='py2.5? ( py2-sources ) py2.6? ( py2-sources ) ... py3.1? ( py3-sources ) py3.2? ( py3-sources )' In practice, it would look like: SRC_URI="$(python_gen_cond_dep py2-sources python2* pypy*) $(python_gen_cond_dep py3-sources python3*)" Variant B: gtk-like slotting + a virtual SLOT py2, ver -r200 with py2 implementations only SLOT py3, ver -r300 with py3 implementations only virtual which pulls in both implementations A pros: simple, one ebuild, no change to deps. A cons: a bit of conditionals. B pros: a bit cleaner prolly. B cons: two ebuilds + virtual, change to deps, uneasy to dep on version. In this case, I think we should really go with A.