Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can com_err.h be installed into a subdirectory instead of the root include directory? #197

Open
adamantoise opened this issue Sep 24, 2024 · 1 comment

Comments

@adamantoise
Copy link

Hello,

While testing out this package, I noticed that in et/Makefile.in, we install the header file from et/com_err.h into the root of the include tree here https://github.com/tytso/e2fsprogs/blob/master/lib/et/Makefile.in#L119-L120 :

	$(Q) (cd $(DESTDIR)$(includedir) ;\
		$(LN) $(LINK_INSTALL_FLAGS) et/com_err.h . )

Would it be possible to change this to install into a subdirectory of the install directory instead, something like this?

	$(Q) (cd $(DESTDIR)$(includedir) ;\
		@mkdir et
		$(LN) $(LINK_INSTALL_FLAGS) et/com_err.h et/ )

The reason for this is that we also have a dependency on the Kerberos library (krb5), which installs its own com_err.h header file to the root of the distribution include directory. This causes a conflict with our build system, since both e2fsprogs and Kerberos are trying to install a header file of the same name into the same location.

@tytso
Copy link
Owner

tytso commented Sep 25, 2024

We do install com_err.h in /usr/include/et/com_err.h already. This is done here[1]. The line which you referred to is the one where we create a link (either a hard link or a symbolic link) for /usr/include/com_err.h which points at /usr/include/et/com_err.h.

[1] https://github.com/tytso/e2fsprogs/blob/v1.47.1/lib/et/Makefile.in#L115

The reason why we maintain a link to the top-level com_err.h is because there are a lot of open source callers which use:

#include <com_err.h>

instead of:

#include <et/com_err.h>

and we don't want to break source code which uses the former rather than the latter.

How to handle conflicts between Kerberos and e2fsprogs is the responsibility of the distribution which is packaging these two packages. In the case of Debian, the krb5 package uses the com_err library from e2fsprogs, and I've worked with the Debian krb5 maintainer to make sure that the various newer interfaces that were added to libcom_err after I stopped working at MIT and stopped being the tech lead for MIT Kerberos, and integrated them into e2fsprogs's libcom_err.h, and so the com_err library for e2fsprogs can be used for Kerberos v5. Debian has a rule that there should only be one version of any library shipped by Debian (this is the "no vendoring rule", because while "Modern programming practices" thinks that having every package shipping their own copy of libraries is a Good Thing, this was the cause of the Log4j securiy disaster).

So first solutoin is to do what Debian's Kerberos v5 does, which is to just simply change Kerberos to use the com_err library for e2fsprogs. This made sense for Debian because all systems have e2fsprogs installed, where not as many Debian systems have Kerberos installled.

The other solution is that many Distribuions have a way of managing symlinks; for example, using the update-alternatives command, you can change /bin/cc to point at /usr/bin/cc or /usr/bin/clang:

% update-alternatives  --query cc
Name: cc
Link: /usr/bin/cc
Status: auto
Best: /usr/bin/gcc
Value: /usr/bin/gcc

Alternative: /usr/bin/clang
Priority: 10

Alternative: /usr/bin/gcc
Priority: 20

So you could in theory have some way of managing whether /usr/include/com_err.h points at /usr/include/et/com_err.h or some other location. But I'd strongly suggest just using e2fsprogs's com_err for krb5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants