Special files we keep or toss in a package on *NIX

Which of the following do we keep or toss?

1. *.pc pkg-config files (placed in $PREFIX/lib/pkgconfig/.... useful for compile options to use with a dependency)
2. *.la libtool files (placed in $PREFIX/lib/. useful for figuring out where libraries live).
3. *.m4 m4 files (clear value during build. some are installed in $PREFIX/share/aclocal. Why? 😕)
4. *.1, *.2, etc. man files (placed in $PREFIX/share/man/.... used by man, which we don’t use).

My vote is keep 1 and 2, but drop 3 and 4. I know cases where 1 has been helpful ( https://github.com/conda-forge/ncurses-feedstock/pull/11 ). There are cases where 2 is important right now I’m debugging one.

I don’t really understand the value of 3. So, drop? Maybe someone with more Linux knowledge (@ocefpaf?) could help us here.

As we can’t use 4 now and it can take up some space, my vote is drop.

If we follow this route, we can just always add rm -rf $PREFIX/share/aclocal and rm -rf $PREFIX/share/man. Though honestly that directory more often than not includes junk so we should be able to always do rm -rf $PREFIX/share.

[scopatz]

Hi @jakirkham - I assume that the m4 files that are installed are installed so that the macros are available to other build systems that depend on whatever package installed them. I think these are most often used by autotools.

As per 4, please please please don’t drop them. This is one of the most frustrating things about other package managers. If I install a package, I definitely expect to get the docs. Furthermore, just because we don’t have a man package, doesn’t mean that users can’t set the $MANPATH to take advantage of these file. Moreover, fish, and to a lesser but growing extent xonsh, uses man pages to find tab completions. It would be a shame to loose this feature from packaging issue (again). Additionally, it is not true that the share dir contains nothing of value. This is the default place projects are supposed to stick custom data. $XDG_DATA_HOME is likely the most famous example of this. Finally, I don’t think that the total space and bandwidth this takes up is significant to worry about.

The advantage of conda and conda-forge to me has always seemed that it has been an opportunity to create and distribute packages that actually contain the full package that the developer intended. The packagers don’t go in there and start meddling with what the package should be. If the developer intended for a file to be installed, as an end user I expect to receive that file when I install it. I feel that this is one of the major failings of apt and other systems.

Just my 2 drachmas, but I do feel pretty strongly about this 😃

[pelson]

Probably in no small part to our full embrace of conda-build as our sole build tool

So I think the problem we were seeing was that /path/to/build/lib/../lib64 was being stored in the .la files. I’m pretty sure this could be achieved with conda-build if the lib64 directory was being used and subsequently renamed by a build script.

If we decide we need to delete them, we need to assess what is affected.

That is always the problem we are going to have. In these kinds of situations, if a Linux distribution has already lead the way and done the research, I’m happy to piggy back on that work.