| 1 |
hasufell posted on Thu, 29 Nov 2012 14:16:18 +0100 as excerpted: |
| 2 |
|
| 3 |
> again, even if there are corner cases which cannot be dealt with in a |
| 4 |
> different way... |
| 5 |
> |
| 6 |
> having an eclass function like the mentioned one is bad, cause it |
| 7 |
> suggests that this is a way to fix things. It's not. Application |
| 8 |
> developers running gentoo might think "oh great, there is a pkgconfig |
| 9 |
> file for this, so I can use it in my Makefile". Then a Fedora packager |
| 10 |
> comes across this package and realizes a compile failure until he |
| 11 |
> notices the build system is calling for a pkgconfig file that cannot be |
| 12 |
> found anywhere. So he contacts this developer and asks which distro he |
| 13 |
> is using. |
| 14 |
> |
| 15 |
> This already happened for me multiple times and the answers was |
| 16 |
> "debian". |
| 17 |
> |
| 18 |
> All this sounds like a very dirty workaround and if you need it, then do |
| 19 |
> it, but _don't_ create an eclass, cause it's not a good thing to |
| 20 |
> standardize. |
| 21 |
> These files should _not_ be distro-dependant. Try to find other |
| 22 |
> solutions. |
| 23 |
> |
| 24 |
> -1 for this eclass |
| 25 |
|
| 26 |
Suggestion/question for Justin, Mike (Spanky), and others. |
| 27 |
|
| 28 |
Assuming people eventually agree that this is a special case, which I'm |
| 29 |
beginning to think it might be after reading Justin's arguments, tho I |
| 30 |
recognize that's not a settled case yet... |
| 31 |
|
| 32 |
The glibc ebuilds use glibc-specific eblits. This keeps the glibc- |
| 33 |
specific common code out of the ebuilds (and out of more general purpose |
| 34 |
eclasses) and in the files dir. |
| 35 |
|
| 36 |
Obviously that specific solution won't work for the multiple blas/ |
| 37 |
whatever packages, since it's single-package/multi-version specific, but |
| 38 |
is there some variant of it that could work, keeping the code out of |
| 39 |
eclasses where the not-for-general-purpose solution might be mistakenly |
| 40 |
thought to be general purpose and get used as such, while still allowing |
| 41 |
a common to the various *blas/whatever packages solution? |
| 42 |
|
| 43 |
The best I can come up with is eblits, thus keeping it out of the |
| 44 |
individual ebuilds, but forcing the eblits to be copied to all the |
| 45 |
different implementations individually. Still, that'd save a bit of code |
| 46 |
between multiple versions of the same package, and a script could be |
| 47 |
setup that updates all the eblits in the various packages in one go, so |
| 48 |
it'd be a bit better than having to do it per ebuild. |
| 49 |
|
| 50 |
But perhaps someone else can improve on that idea... |
| 51 |
|
| 52 |
Another alternative might be an eclass, but name it something like blas- |
| 53 |
utils or some such, not pkgconfig, thus discouraging inappropriate use, |
| 54 |
and put in strict warnings and possibly repoman checks, so that only a |
| 55 |
specific list of packages are allowed to use it. That list could then be |
| 56 |
controlled by either the science or QA teams as thought appropriate, thus |
| 57 |
strictly limiting the spread of this ordinarily inappropriate practice. |
| 58 |
|
| 59 |
-- |
| 60 |
Duncan - List replies preferred. No HTML msgs. |
| 61 |
"Every nonfree program has a lord, a master -- |
| 62 |
and if you use the program, he is your master." Richard Stallman |
Archives