This can be named in various different ways, especially in cross-compilation
environments, so let's take it from the build setup.
This is a much simpler and less invasive version of an earlier patch: it simply
changes references to $(prefix)/lib/rpm, so that they become $(libdir)/rpm.
Hopefully
this will break existing distributions.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/298#issuecomment-319643940___
Rpm-maint m
I just want to settle this question going forward: should these references be
hardcoded to /usr/lib, which is less pain for existing distributions, but more
pain for Yocto, as we have to fix every instance of such hard coding (that also
includes the rest of dnf stack, and various other software)
@kanavin I still don't understand why $prefix/lib/rpm is a problem. This
location is even described in FHS. so Yocto doesn't support FHS?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manage
> /usr/lib includes object files and libraries. [21] On some systems, it may
> also include internal binaries that are not intended to be executed directly
> by users or shell scripts. [22]
> ...
> [22] See below, in the /usr/libexec section, for a discussion of /usr/lib vs.
> /usr/libexec for
It is a problem for multilib environments which are very common in embedded
space. Yocto has had full support for it for a long time, but it does require
that nothing hardcodes the /usr/lib assumption, and instead installs its stuff
where it is told to by the build environment.
http://www.yoctop
The Yocto Project doesn't mandate any particular userspace layout. You can
configure it to match FHS but we expect software to match the configuration
that is set. The issue here is that rpm doesn't honour our configuration
settings. People can and do change the layouts for various reasons, I do
NAK, $(libdir) is simply wrong for this purpose. It's decidedly a literal
"/usr/lib/rpm", as per FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
If you really need to be able to override the directory, submit a patch that
adds an a configure option to do so f
@pmatilai You are selectively quoting the FHS. Just a bit further it says:
> /usr/lib : Alternate format libraries (optional)
> Purpose
>
> /usr/lib performs the same role as /usr/lib for an alternate binary
> format,
>
So no, you cannot hardcode a literal /usr/lib/whatever anywhere in source
@kanavin so what's the deal with systemd, casync and others who use
$prefix/lib/$name instead of $libexecdir/$name?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/298#issu
The way I read the FHS is that it does not allow you to hardcode $prefix/lib,
and it implicitly stipulates that helper executables go to $libdir/$name.
The way I read GNU coding standards is that helper executables should go to
$libexecdir/$name.
I believe systemd, rpm, etc. violate both, perh
@kanavin @ignatenkobrain @pmatilai FHS 3.0 explicitly allows `/usr/libexec`
(aka `$libexecdir`), so using that path is not in violation of FHS.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-
@Conan-Kudo Yes, I forgot to check that 2.3 is not in fact the latest FHS. That
would be my preferred solution: helper binaries go to $libexecdir/rpm, data
goes to $datadir/rpm, any software that makes different assumptions and becomes
broken because of the change gets fixed.
--
You are recei
@kanavin I think if you prepare a patch to make this configurable (as @pmatilai
suggested) and fix the assumptions within RPM itself, that would go a long way.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
I still think it is terribly wrong...
* https://lists.fedoraproject.org/pipermail/devel/2012-December/175518.html
* https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
@Conan-Kudo I would rather not introduce special non-standard --rpmconfigdir
--rpmlibexecdir flags to ./configure, where the defaults continue to violate
established standards and practice. I'd rather go with using $libexecdir
(alternatively, $libdir) and $datadir, or simply continue to carry a
Of course everybody is reading the FHS selectively, isn't that what standards
are for...
Anyway, I'm not breaking 20+ years of compatibility (again, the /usr/lib/rpm
path is hardcoded in LOTS of packages and other software out there) just
because. I've expressed what would be acceptable to rpm,
Closed #298.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/298#event-1209769103___
Rpm-maint mailing list
Rpm-maint@lists.rpm.o
18 matches
Mail list logo
