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 |