| 1 |
On 05-10-2010 12:03, Diego Elio Pettenò wrote: |
| 2 |
> Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto: |
| 3 |
>> |
| 4 |
>> Like Richard said "Gentoo is about choice... |
| 5 |
>> |
| 6 |
>> By removing .la files, you are taking away that choice from the user. |
| 7 |
>> For you they might be useless, for some user (or entire software |
| 8 |
>> house) |
| 9 |
>> it can be its holly grail for library versioning and linking. I don't |
| 10 |
>> really feel like forcing users to change their build setups just |
| 11 |
>> because |
| 12 |
>> we think they are useless, do you? |
| 13 |
>> - It is decisions like this one that *might* give us bad reputation. |
| 14 |
>> |
| 15 |
>> Should we also start removing package-config files just because there |
| 16 |
>> are better ways to detect if a certain package is installed? |
| 17 |
> |
| 18 |
> Again, I ask you: how do libtool archive work? What is lost by removing |
| 19 |
> them? How can any software out there rely on them? |
| 20 |
|
| 21 |
You can extract from a .la things like the library name, version and |
| 22 |
linking information (lib dependencies and paths). The information is |
| 23 |
there and nothing prevented anyone from using it. |
| 24 |
> |
| 25 |
> Can you provide any specific use case, or are you now arguing for |
| 26 |
> "choice for choice's sake"? |
| 27 |
|
| 28 |
There are a lot of packages that need this information to correctly link |
| 29 |
against libtool managed libraries, for example, there are packages that |
| 30 |
linked against GL but didn't set -lGL -lGLU because it was relying on |
| 31 |
libtool to get that information (guess from where?). Things get worse |
| 32 |
when they also expect libtool to also provide libraries path. There are |
| 33 |
even packages that expects libtool to provide linker flags for its |
| 34 |
direct dependencies and flags for the dependencies of its dependencies. |
| 35 |
For example: |
| 36 |
foo links with GL (expects libtool to provide -lGL -lGLU) |
| 37 |
foo also links with the backend of GL (expects libtool to provide -lX11 |
| 38 |
for example, which is a dependency of GL) |
| 39 |
|
| 40 |
In a perfect world everyone would be using pkg-config or whatever, but |
| 41 |
not. I happen to be bitching about this because I came across some of |
| 42 |
these when cross-compiling. |
| 43 |
> |
| 44 |
> Should we remove /usr/bin/xml2-config? No. Why? Because there are |
| 45 |
> packages out there not using pkg-config to detect libxml2, upstream |
| 46 |
> libxml2 provides that explicitly and allows it to be used as such: |
| 47 |
> |
| 48 |
> $(CC) $(CFLAGS) $(LDFLAGS) `xml2-config --cflags` foo.c -o foo |
| 49 |
> `xml2-config --libs` |
| 50 |
> |
| 51 |
> Should we remove /usr/lib/libxml2.la? Yes. Why? Because upstream does |
| 52 |
> not explicitly provide it (it's a byproduct of libtool), and they don't |
| 53 |
> require/ask to rely on it (otherwise it wouldn't provide pkg-config |
| 54 |
> or .pc files). |
| 55 |
> |
| 56 |
> Again, I'm not arguing over semantics or feelings here, I'm arguing with |
| 57 |
> facts; can you argue with facts or are you just going to quote Richard |
| 58 |
> again and propose "choice for choice's sake"? |
| 59 |
> |
| 60 |
|
| 61 |
Mind you that the community is wider than one can imagine. I happen to |
| 62 |
work in the academia and I know a lot of nasty stuff people do to save |
| 63 |
time (at least is what they think) for deadlines. As a user, I would |
| 64 |
hate to have my research program/script broken just because some dev |
| 65 |
decided to make the distribution I use his personal sandbox. |
| 66 |
|
| 67 |
Besides, doesn't this kind of changes belong in upstream and then |
| 68 |
eventually come to the distros? Why don't you make a patch and send |
| 69 |
upstream if these libtool files are so useless? |
Archives