On 30.11.2012 05:37, Duncan wrote: > 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. >
Thanks for making thoughts about this issue. Meanwhile I talked back to my team lead and he told me that the final solution will be without pc files. This is work in progress, but it will be pc file free and alos not bypassing the buildsystem in anyway. But lets wait. Thanks, Justin
signature.asc
Description: OpenPGP digital signature
