pld rpm 5.4.17

[Jeffrey Johnson]

> On Jan 12, 2017, at 2:26 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> 
> By the way - are there any plans to implement fcaps in rpm5?
> (like in rpm.org since 4.7.0)
> 
> e.g. mtr.spec looks sad with
> %attr(4755,root,root) %{_bindir}/mtr
> instead of %caps(cap_net_raw=ep)…
> 

The problem I have with capabilities in RPM attached to files is how to represent the values.

Adding an entire array for every file in order to attach a couple of values is rather overkill.

Even if the tag is optional (which has other runtime issues testing return codes everywhere),
its kinda hard (IMHO) to justify the bloat for the handful of files that would benefit from capabilities.
There’s some subtle hackery that could be done for efficiency, but the hackery would
most definitely be incompatible with the existing rpm.org representation.

And if capabilities are implemented, then act’s and xattr’s (beyond SELinux) likely should be implemented too.

(aside)
What RPM needs is a way to handle sparse arrays, with memorization for repeated values. This
is one of (of many) constraints on the existing header format. I am currently looking at
flatcc flat buffers as a possible replacement for existing Headers, and there is some
hope that flat buffers can/will handle
	* a sparse array (for capabilities and other sparse arrays),
	* a mapping (to replace RPM_I18NSTRING_TYPE removal)
	* an array of RPM_BIN_TYPE (so that file digests don’t need to be represented in hex)
but I’m some months away from attempting flat buffers in “production” RPM.

The rpm.org syntax could be parsed pretty easily, with associated ignore/warning/error messages
if that helps. However implementing the syntax without adding the values to a header
likely creates False Hope for users, and I’m trying to resist adding bloat/change everywhere
to support capabilities as a “feature”.

Does my explanation make sense?

I’m certainly willing to discuss further if you wish, can easily generate a patch for you
(but I’d like not to maintain that patch upstream, “legacy compatibility” usually
takes years to undo or fix correctly in RPM.

AFAIK there’s only a handful of files that benefit from capabilities (but I haven’t looked recently: for all I know
there may be tens of thousands of files that now use/need capabilities these days).

FWIW: handling capabilities (and acls/xattrs) within %post/%preun/%verifyscript scriptlets isn’t
all *THAT* ugly. JMHO, YMMV.