| 1 |
Sure, this is a more complex problem. |
| 2 |
|
| 3 |
My point is, for pkg-config files it is relatively easy to fix stuff |
| 4 |
that depends on non-standard files (I can write a devmanual section |
| 5 |
about that, but err... this is really trivial). The amount of these |
| 6 |
downstream pkg-config files is not as big as you might think (yet). So |
| 7 |
just saying "no" to all new downstream additions will not cause a big |
| 8 |
explosion and thousands of packages failing to build. Look at the |
| 9 |
tracker, it's just a few we know of. Cmake is mostly not affected, |
| 10 |
autotools is often complex enough to still find the libs, Makefiles need |
| 11 |
a one-line patch. And, by the time we discover more, we can work towards |
| 12 |
removing them. |
| 13 |
|
| 14 |
It will raise awareness about this problem and about the fact that |
| 15 |
distros like debian tend to do it the lazy way. |
| 16 |
So it is a pretty easy way to improve portability across distros and so on. |
| 17 |
|
| 18 |
We shouldn't do things wrong just because they didn't blow up in our |
| 19 |
face yet. |
| 20 |
|
| 21 |
I am confused why this gets so much attention. The additional workload |
| 22 |
is really minor. So, not allowing this makes sense to me. |
| 23 |
For exotic exceptions and corner cases, we can still bend the rules. |
| 24 |
But, "debian does it too" is not one. |
Archives