BTW it appears that the macros.systemtap are going to be part of systemtap-devel [1], while for ruby, we are using just systemtap-sdt-devel. Not sure if it makes sense to move them into systemtap-sdt-devel ...



[1] https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=blob;f=systemtap.spec;h=4392b1be6b5a4d7343020122e4b6c7bf436aa11c;hb=HEAD#l1013

For multilib support, you can probably use the auto-path facility added to systemtap in 2016: https://sourceware.org/bugzilla/show_bug.cgi?id=10485.  This lets you install boilerplate .stp files for your shlibs in paths that literally match the shlibs' own install path.  So you don't have to substring %{_libdir}, just concatenate it to %{_systemtap_tapset_dir}/PATH/ e.g.

For systemtap dependency issues, I suggest not worrying about it.  Feel free to put your .stp files right under the normal stap tapset directory (so you don't need %tapset_root, only %tapset_dir).

For inclusion of these macros in the -sdt-devel subrpm instead of -devel: you're right, will move the file over.

(In reply to Frank Ch. Eigler from comment #2)
> For systemtap dependency issues, I suggest not worrying about it.  Feel free
> to put your .stp files right under the normal stap tapset directory (so you
> don't need %tapset_root, only %tapset_dir).

That is wrong, because if you install the package containing the .stp file and then you remove it, the %tapset_root will remain on the filesystem, because it is not owned by anything. So either systemtap must be installed to own that directory or the package owning the .stp file must own the %tapset_root

(In reply to Frank Ch. Eigler from comment #2)
> For multilib support, you can probably use the auto-path facility added to
> systemtap in 2016: https://sourceware.org/bugzilla/show_bug.cgi?id=10485. 
> This lets you install boilerplate .stp files for your shlibs in paths that
> literally match the shlibs' own install path.  So you don't have to
> substring %{_libdir}, just concatenate it to %{_systemtap_tapset_dir}/PATH/
> e.g.

Thx for the tip. Will check that.

(In reply to Vít Ondruch from comment #3)
> (In reply to Frank Ch. Eigler from comment #2)
> > For systemtap dependency issues, I suggest not worrying about it.  Feel free
> > to put your .stp files right under the normal stap tapset directory (so you
> > don't need %tapset_root, only %tapset_dir).
> 
> That is wrong, because if you install the package containing the .stp file
> and then you remove it, the %tapset_root will remain on the filesystem,
> because it is not owned by anything.

Sorry, I don't understand.  The tapset directory /usr/share/systemtap/tapset is indeed 'owned' by systemtap's rpms (in the sense of rpm -ql listing them), as well as other packages that deposit files underneath it.  Even if after uninstallation of all that, an empty directory were somehow to remain, that wouldn't be a big problem either.

Can you be more specific about your concern, and for what values of the hypothetical macros they would apply?

Let me give you an example.

Given that my package ships file /usr/share/systemtap/tapset/foo.stp and it does not depend on systemtap and systemtap is not installed on the system.

If my file section has this entries:

~~~
%files
%tapset_dir
~~~

This will indeed include the foo.stp file. But if I install and then remove my package, it will leave the /usr/share/systemtap/ on the filesystem. This can be solved by owning the /usr/share/systemtap/, e.g.:

~~~
%files
/usr/share/systemtap/
~~~

This would own the whole directory structure properly and won't left anything behind after package removal.

ISTM that if rpm is the one creating the intermediate parent directory (/usr/share/systemtap) on its own initiative, it should track its ownership.  In any case, an empty directory entry left behind is not that big a deal.  (I'm not opposed to another macro that permits other subrpms to do what you propose.  But I would not mandate or even suggest them to fix what seems like an rpm problem.)

commit 57c000237333

(In reply to Frank Ch. Eigler from comment #7)
> ISTM that if rpm is the one creating the intermediate parent directory
> (/usr/share/systemtap) on its own initiative, it should track its ownership.

RPM is not creating anything. Package maintainer is creating such directory in %install section [1] by ```mkdir -p %{buildroot}%{tapset_dir}```.

RPM can track the ownership of the directory structure, but you have to own the root of the structure, e.g. [2].


[1] https://src.fedoraproject.org/rpms/ruby/blob/8ef3cc0ed4d2f8626492b3f16157ab890017f210/f/ruby.spec#_689
[2] https://src.fedoraproject.org/rpms/ruby/blob/8ef3cc0ed4d2f8626492b3f16157ab890017f210/f/ruby.spec#_924

The %install section is not too directly related to the %files section.

(In reply to Frank Ch. Eigler from comment #9)
> The %install section is not too directly related to the %files section.

What is done in the %install section directly relates to %files section, otherwise RPM complains.

> In any case, an empty directory entry left behind is not that big a deal.

This is what Fedora Packaging Guidelines [1] says about directory ownership:

~~~
Packages must own all directories they put files in
~~~

So what you claim contradicts the guidelines. Even if the guidelines did not contain this clause, it would be just common sense to clean up everything after uninstall.

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership

I hate to belabour the point much further, but:

% cat foo.spec
Name: foo
Version: 1
Release: 1
License: None
Summary: None
%description
None

%prep

%build

%install

mkdir -p $RPM_BUILD_ROOT/foo/bar/baz

%files
%dir /foo/bar/baz

% rpmbuild -ba foo.spec
                           <-- note no warnings about intermediate directories
% rpm -qlp PATH_TO_RPM
/foo/bar/baz               <-- observe no intermediate directories

% rpm -i PATH_TO_RPM
                           <-- observe rpm created /foo and /foo/bar
% rpm -e foo
                           <-- observe rpm left behind /foo and /foo/bar

Yes, this is wrong .spec file indeed. You have to own the whole directory structure you create you create. I.e. this should be the correct content of %files section:

~~~
%files
/foo
~~~

And this is equivalent to:

~~~
%files
%dir /foo
%dir /foo/bar
%dir /foo/bar/baz
~~~

if you want to be explicit.

IOW only the topmost directory and possibly its content is owned by RPM because the rest might be owned by some other package.

And you are right, that RPM does not complain about empty directories, because directories are hard and historically RPM did much worse handling directories, but we should not use it as an excuse.