Gentoo Archives: gentoo-dev

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

Attachments

File name MIME type
signature.asc application/pgp-signature