From: Andrea Claudi <aclaudi@redhat.com>
To: Petr Machata <petrm@nvidia.com>
Cc: luca.boccassi@gmail.com, netdev@vger.kernel.org,
stephen@networkplumber.org
Subject: Re: [PATCH iproute2] Revert "Makefile: ensure CONF_USR_DIR honours the libdir config"
Date: Fri, 10 Nov 2023 21:31:17 +0100 [thread overview]
Message-ID: <ZU6TFWw9UuBkRazb@renaissance-vector> (raw)
In-Reply-To: <87bkc1yaqa.fsf@nvidia.com>
On Fri, Nov 10, 2023 at 02:54:16PM +0100, Petr Machata wrote:
>
> Petr Machata <petrm@nvidia.com> writes:
>
> > luca.boccassi@gmail.com writes:
> >
> >> From: Luca Boccassi <bluca@debian.org>
> >>
> >> LIBDIR in Debian and derivatives is not /usr/lib/, it's
> >> /usr/lib/<architecture triplet>/, which is different, and it's the
> >> wrong location where to install architecture-independent default
> >> configuration files, which should always go to /usr/lib/ instead.
> >> Installing these files to the per-architecture directory is not
> >> the right thing, hence revert the change.
> >
> > So I looked into the Fedora package. Up until recently, the files were
> > in /etc, but it seems there was a deliberate change in the spec file
> > this September that moved them to /usr/lib or /usr/lib64.
> >
> > Luca -- since you both sent the patch under reversion, and are Fedora
>
> Ugh, I mean Andrea, not Luca. Sorry!
>
> > maintainer, could you please elaborate on what the logic was behind it?
> > It does look odd to me to put config files into an arch-dependent
> > directory, but I've been out of packaging for close to a decade at this
> > point.
Hi Petr,
the change in Fedora iproute package is in response to 0a0a8f12fa1b
("Read configuration files from /etc and /usr"): it moves config files
from /etc to /usr to make room for customization using /etc/iproute2, as
described over there.
What I tried to achieve with my patch is to have a single location in
/usr for iproute files; but I agree with both you and Luca that storing
config files in an arch-dependent directory doesn't look right.
However, even using /usr/lib doesn't seems quite right to me. According
to the FHS [1]:
"/usr/lib includes object files and libraries. On some systems, it may
also include internal binaries that are not intended to be executed
directly by users or shell scripts."
A better location is probably /usr/share [2]:
"The /usr/share hierarchy is for all read-only architecture independent
data files.
This hierarchy is intended to be shareable among all architecture
platforms of a given OS; thus, for example, a site with i386, Alpha, and
PPC platforms might maintain a single /usr/share directory that is
centrally-mounted."
And this is exactly our case: read-only, shareable, config files that
can be overridden using /etc/iproute2.
Luca, does something along the lines below work for you? If so, I can
test and send a patch fixing my own stuff.
diff --git a/Makefile b/Makefile
index 5c559c8d..ec57bd4c 100644
--- a/Makefile
+++ b/Makefile
@@ -16,11 +16,11 @@ endif
PREFIX?=/usr
SBINDIR?=/sbin
+DATADIR?=$(PREFIX)/share
CONF_ETC_DIR?=/etc/iproute2
-CONF_USR_DIR?=$(LIBDIR)/iproute2
+CONF_USR_DIR?=$(DATADIR)/iproute2
NETNS_RUN_DIR?=/var/run/netns
NETNS_ETC_DIR?=/etc/netns
-DATADIR?=$(PREFIX)/share
HDRDIR?=$(PREFIX)/include/iproute2
DOCDIR?=$(DATADIR)/doc/iproute2
MANDIR?=$(DATADIR)/man
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html
[2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html
next prev parent reply other threads:[~2023-11-10 20:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 0:14 [PATCH iproute2] Revert "Makefile: ensure CONF_USR_DIR honours the libdir config" luca.boccassi
2023-11-10 13:34 ` Petr Machata
2023-11-10 13:54 ` Petr Machata
2023-11-10 20:31 ` Andrea Claudi [this message]
2023-11-10 22:01 ` Luca Boccassi
2023-11-10 13:54 ` Luca Boccassi
2023-11-13 16:40 ` patchwork-bot+netdevbpf
2023-11-13 18:12 ` Andrea Claudi
2023-11-13 23:38 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZU6TFWw9UuBkRazb@renaissance-vector \
--to=aclaudi@redhat.com \
--cc=luca.boccassi@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=petrm@nvidia.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.