All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.