hasufell posted on Thu, 29 Nov 2012 14:16:18 +0100 as excerpted:

> again, even if there are corner cases which cannot be dealt with in a
> different way...
> 
> having an eclass function like the mentioned one is bad, cause it
> suggests that this is a way to fix things. It's not. Application
> developers running gentoo might think "oh great, there is a pkgconfig
> file for this, so I can use it in my Makefile". Then a Fedora packager
> comes across this package and realizes a compile failure until he
> notices the build system is calling for a pkgconfig file that cannot be
> found anywhere. So he contacts this developer and asks which distro he
> is using.
> 
> This already happened for me multiple times and the answers was
> "debian".
> 
> All this sounds like a very dirty workaround and if you need it, then do
> it, but _don't_ create an eclass, cause it's not a good thing to
> standardize.
> These files should _not_ be distro-dependant. Try to find other
> solutions.
> 
> -1 for this eclass

Suggestion/question for Justin, Mike (Spanky), and others.

Assuming people eventually agree that this is a special case, which I'm 
beginning to think it might be after reading Justin's arguments, tho I 
recognize that's not a settled case yet...

The glibc ebuilds use glibc-specific eblits.  This keeps the glibc-
specific common code out of the ebuilds (and out of more general purpose 
eclasses) and in the files dir.

Obviously that specific solution won't work for the multiple blas/
whatever packages, since it's single-package/multi-version specific, but 
is there some variant of it that could work, keeping the code out of 
eclasses where the not-for-general-purpose solution might be mistakenly 
thought to be general purpose and get used as such, while still allowing 
a common to the various *blas/whatever packages solution?

The best I can come up with is eblits, thus keeping it out of the 
individual ebuilds, but forcing the eblits to be copied to all the 
different implementations individually.  Still, that'd save a bit of code 
between multiple versions of the same package, and a script could be 
setup that updates all the eblits in the various packages in one go, so 
it'd be a bit better than having to do it per ebuild.

But perhaps someone else can improve on that idea...

Another alternative might be an eclass, but name it something like blas-
utils or some such, not pkgconfig, thus discouraging inappropriate use, 
and put in strict warnings and possibly repoman checks, so that only a 
specific list of packages are allowed to use it.  That list could then be 
controlled by either the science or QA teams as thought appropriate, thus 
strictly limiting the spread of this ordinarily inappropriate practice.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply via email to