Should macro packages co-own /usr/lib/rpm/macros.d, require rpm or do nothing?

[Miro Hrončok]

Hello packagers,

I'd like some guidance wrt RPM packages installing macro files to 
%{rpmmacrodir} (/usr/lib/rpm/macros.d).

Technically this directory is owned by rpm. So following the guidelines at 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_dire... 
such packages should either explicitly require rpm or co-won the directory.

However, our ...-macros packages don't usually do either. Should they? Or is 
the "this is RPM, it's always going to be there" argument stronger than the

rules? Is RPM actually always guaranteed to be there?

We currently have:

$ repoquery --repo=rawhide -q -f '/usr/lib/rpm/macros.d/*' | pkgname
GConf2
Lmod
MUMPS-srpm-macros
adobe-mappings-cmap-devel
adobe-mappings-pdf-devel
ansible-packaging
ansible-srpm-macros
blender-rpm-macros
blis-srpm-macros
build-constraints-rpm-macros
build2-rpm-macros
clang-devel
cmake-rpm-macros
color-filesystem
copr-frontend-devel
cups-devel
drupal7
drupal7-rpmbuild
efi-srpm-macros
emacs-common
environment-modules
erlang-rpm-macros
fdupes
fedora-gnat-project-common
fedora-release-common
fedora-rpm-macros
ffcall-devel
firewalld-filesystem
folly-rpm-macros
folly-srpm-macros
fonts-rpm-macros
fonts-srpm-macros
fpc-srpm-macros
g2clib-devel
gap-rpm-macros
generic-release-common
ggz-base-libs-devel
ghc-rpm-macros
ghc-rpm-macros-extra
ghc-srpm-macros
gimp-devel
gnat-srpm-macros
gnustep-make
go-rpm-macros
go-srpm-macros
grantlee-qt5-devel
grass-devel
hdf5-devel
httpd-devel
javapackages-bootstrap
javapackages-common
javapackages-filesystem
javapackages-tools
kde-apps-rpm-macros
kde-filesystem
kdevelop-devel
kernel-rpm-macros
kernel-srpm-macros
keyrings-filesystem
kf5-kinit-devel
kf5-rpm-macros
kmodtool
ldc
libint-devel
libint2-devel
liblxqt-devel
libvmaf-devel
lpf
lua-rpm-macros
lua-srpm-macros
meson
mingw-filesystem-base
mingw32-filesystem
mingw32-python3
mingw32-python3-build
mingw64-filesystem
mingw64-python3
mingw64-python3-build
mpich-devel
multilib-rpm-config
musl-devel
nginx-mod-devel
nim-srpm-macros
ninja-build
nodejs-packaging
ocaml-srpm-macros
octave-devel
openblas-srpm-macros
openmpi-devel
osc
package-notes-srpm-macros
pam
perl-Future-AsyncAwait-ExtensionBuilder
perl-Object-Pad-ExtensionBuilder
perl-XS-Parse-Keyword-Builder
perl-XS-Parse-Sublike-Builder
perl-macros
perl-srpm-macros
pesign
php-devel
php-pear
pkgconf
polkit-qt-devel
postgresql-server-devel
postgresql-test-rpm-macros
postgresql-upgrade-devel
pyproject-rpm-macros
pypy-devel
pypy3.9-devel
python-pyqt6-rpm-macros
python-qt5-rpm-macros
python-rpm-macros
python-srpm-macros
python2.7
python3-rpm-macros
qt-devel
qt5-qtbase-common
qt5-qtwebengine-devel
qt5-rpm-macros
qt5-srpm-macros
qt6-qtbase-common
qt6-rpm-macros
qt6-srpm-macros
redhat-rpm-config
redis-devel
rpmautospec-rpm-macros
ruby-devel
rubygems-devel
rust-packaging
rust-srpm-macros
sblim-cmpi-devel
scl-utils-build
scl-utils-build-helpers
selinux-policy
shogun-data
sip
sugar-toolkit-gtk3
systemd-rpm-macros
systemtap-sdt-devel
texlive-base
typelib-srpm-macros
ucrt64-filesystem
urw-base35-fonts-devel
vagrant
vdr-devel
vim-filesystem
web-assets-devel
yast2-devtools
zig-rpm-macros

Out of those, only 2 co-own the directory:

javapackages-bootstrap
python2.7

And only a handful requires RPM.


I could think of two categories of packages installing macros to that directory:

  1) packages that primarily exist to ship the macros
  2) packages that ship macros in addition to their primary function

I think packages from (1) should require rpm (even transitively) and packages 
from (2) should co-own the directory. Does that make sense?

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Björn Persson]

Miro Hrončok wrote:
>  Or is 
>  the "this is RPM, it's always going to be there" argument stronger than the
>
>  rules? Is RPM actually always guaranteed to be there? 
Well, if RPM somehow isn't there, does it still matter whether a
directory is owned by any RPM package? What does it even mean for an
RPM package to own a directory when there is no RPM keeping track of
that ownership?

Björn Persson

[Miro Hrončok]

On 16. 01. 23 18:13, Björn Persson wrote:
>  Miro Hrončok wrote:
> > Or is
> > the "this is RPM, it's always going to be there" argument stronger than
> the
> > rules? Is RPM actually always guaranteed to be there?
>  
>  Well, if RPM somehow isn't there, does it still matter whether a
>  directory is owned by any RPM package? What does it even mean for an
>  RPM package to own a directory when there is no RPM keeping track of
>  that ownership? 
Well, I thought about that as well. What if the RPM that installs/manages the 
packages is executed from outside of a chroot/mock/nspawn thing?

See this:

$ mock -r fedora-rawhide-x86_64 init
...
$ mock -r fedora-rawhide-x86_64 --remove rpm
...
$ mock -r fedora-rawhide-x86_64 --dnf-cmd repoquery --installed -f 
/usr/lib/rpm/macros.d/macros.dist
...
fedora-release-common-0:38-0.15.noarch
...
$ mock -r fedora-rawhide-x86_64 --dnf-cmd repoquery --installed -f 
/usr/lib/rpm/macros.d
...
(no package listed)
...

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Vít Ondruch]

Good catch. Can we have dependency generator for this?

BTW the guidelines could include this information:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_of_...


Vít


Dne 16. 01. 23 v 17:54 Miro Hrončok napsal(a):
>  Hello packagers,
>
>  I'd like some guidance wrt RPM packages installing macro files to 
>  %{rpmmacrodir} (/usr/lib/rpm/macros.d).
>
>  Technically this directory is owned by rpm. So following the 
>  guidelines at 
>  https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_dire...
>
>  such packages should either explicitly require rpm or co-won the 
>  directory.
>
>  However, our ...-macros packages don't usually do either. Should they? 
>  Or is the "this is RPM, it's always going to be there" argument 
>  stronger than the rules? Is RPM actually always guaranteed to be there?
>
>  We currently have:
>
>  $ repoquery --repo=rawhide -q -f '/usr/lib/rpm/macros.d/*' | pkgname
>  GConf2
>  Lmod
>  MUMPS-srpm-macros
>  adobe-mappings-cmap-devel
>  adobe-mappings-pdf-devel
>  ansible-packaging
>  ansible-srpm-macros
>  blender-rpm-macros
>  blis-srpm-macros
>  build-constraints-rpm-macros
>  build2-rpm-macros
>  clang-devel
>  cmake-rpm-macros
>  color-filesystem
>  copr-frontend-devel
>  cups-devel
>  drupal7
>  drupal7-rpmbuild
>  efi-srpm-macros
>  emacs-common
>  environment-modules
>  erlang-rpm-macros
>  fdupes
>  fedora-gnat-project-common
>  fedora-release-common
>  fedora-rpm-macros
>  ffcall-devel
>  firewalld-filesystem
>  folly-rpm-macros
>  folly-srpm-macros
>  fonts-rpm-macros
>  fonts-srpm-macros
>  fpc-srpm-macros
>  g2clib-devel
>  gap-rpm-macros
>  generic-release-common
>  ggz-base-libs-devel
>  ghc-rpm-macros
>  ghc-rpm-macros-extra
>  ghc-srpm-macros
>  gimp-devel
>  gnat-srpm-macros
>  gnustep-make
>  go-rpm-macros
>  go-srpm-macros
>  grantlee-qt5-devel
>  grass-devel
>  hdf5-devel
>  httpd-devel
>  javapackages-bootstrap
>  javapackages-common
>  javapackages-filesystem
>  javapackages-tools
>  kde-apps-rpm-macros
>  kde-filesystem
>  kdevelop-devel
>  kernel-rpm-macros
>  kernel-srpm-macros
>  keyrings-filesystem
>  kf5-kinit-devel
>  kf5-rpm-macros
>  kmodtool
>  ldc
>  libint-devel
>  libint2-devel
>  liblxqt-devel
>  libvmaf-devel
>  lpf
>  lua-rpm-macros
>  lua-srpm-macros
>  meson
>  mingw-filesystem-base
>  mingw32-filesystem
>  mingw32-python3
>  mingw32-python3-build
>  mingw64-filesystem
>  mingw64-python3
>  mingw64-python3-build
>  mpich-devel
>  multilib-rpm-config
>  musl-devel
>  nginx-mod-devel
>  nim-srpm-macros
>  ninja-build
>  nodejs-packaging
>  ocaml-srpm-macros
>  octave-devel
>  openblas-srpm-macros
>  openmpi-devel
>  osc
>  package-notes-srpm-macros
>  pam
>  perl-Future-AsyncAwait-ExtensionBuilder
>  perl-Object-Pad-ExtensionBuilder
>  perl-XS-Parse-Keyword-Builder
>  perl-XS-Parse-Sublike-Builder
>  perl-macros
>  perl-srpm-macros
>  pesign
>  php-devel
>  php-pear
>  pkgconf
>  polkit-qt-devel
>  postgresql-server-devel
>  postgresql-test-rpm-macros
>  postgresql-upgrade-devel
>  pyproject-rpm-macros
>  pypy-devel
>  pypy3.9-devel
>  python-pyqt6-rpm-macros
>  python-qt5-rpm-macros
>  python-rpm-macros
>  python-srpm-macros
>  python2.7
>  python3-rpm-macros
>  qt-devel
>  qt5-qtbase-common
>  qt5-qtwebengine-devel
>  qt5-rpm-macros
>  qt5-srpm-macros
>  qt6-qtbase-common
>  qt6-rpm-macros
>  qt6-srpm-macros
>  redhat-rpm-config
>  redis-devel
>  rpmautospec-rpm-macros
>  ruby-devel
>  rubygems-devel
>  rust-packaging
>  rust-srpm-macros
>  sblim-cmpi-devel
>  scl-utils-build
>  scl-utils-build-helpers
>  selinux-policy
>  shogun-data
>  sip
>  sugar-toolkit-gtk3
>  systemd-rpm-macros
>  systemtap-sdt-devel
>  texlive-base
>  typelib-srpm-macros
>  ucrt64-filesystem
>  urw-base35-fonts-devel
>  vagrant
>  vdr-devel
>  vim-filesystem
>  web-assets-devel
>  yast2-devtools
>  zig-rpm-macros
>
>  Out of those, only 2 co-own the directory:
>
>  javapackages-bootstrap
>  python2.7
>
>  And only a handful requires RPM.
>
>
>  I could think of two categories of packages installing macros to that 
>  directory:
>
>   1) packages that primarily exist to ship the macros
>   2) packages that ship macros in addition to their primary function
>
>  I think packages from (1) should require rpm (even transitively) and 
>  packages from (2) should co-own the directory. Does that make sense?
>
>

[Miro Hrončok]

On 16. 01. 23 18:19, Vít Ondruch wrote:
>  Good catch. Can we have dependency generator for this? 
Not if co-owning is one of the recommended options.

>  BTW the guidelines could include this information:
>  
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_of_...
My plan is to propose a guideline after this discussion settles.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Neal Gompa]

On Mon, Jan 16, 2023 at 12:46 PM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 16. 01. 23 18:19, Vít Ondruch wrote:
>  > Good catch. Can we have dependency generator for this?
>
>  Not if co-owning is one of the recommended options.
>
>  > BTW the guidelines could include this information:
>  >
>  >
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_of_...
>
>  My plan is to propose a guideline after this discussion settles.
>  
We could add the directory to filesystem or create an rpm-filesystem
package to own the user layer directories?



-- 
真実はいつも一つ！/ Always, there's only one truth!