[Bug 993324] Review Request: ell - Embedded LL library

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=993324



--- Comment #5 from Michael Schwendt <bugs.michael at gmx.net> ---
> We can

Ah, that's the connection between "can" => "shouldn't".

Yes, it would be possible to not build "ell-devel" but just "ell". There are no
naming guidelines about it. The FPC considers it okay when an implicitly
development related package doesn't add "-devel" to its name, if there is no
need for a package split between run-time and build-time files. E.g. the
package of a compiler or similar tool may contain headers (and even libs)
without becoming a -devel package.

Whether that is good and convenient also for pure API packages is debatable.
The thousands of -devel packages in the collection are considered fully
optional and unnecessary at run-time, so one may remove them from an
installation for various reasons. So far, it has been possible to use tools
like rpmdev-rmdevelrpms or simple RPM queries to do that. The guidelines even
comment on that with regard to removing all developer-related packages in an
attempt at finding missing build requirements. It's helpful if header-only APIs
are stored in -devel packages, too.


> And just add virtual provides.

For a non-virtual package name, they are automatic and versioned and even use
%_isa. Adding them manually complicates matters. Introducing virtual package
names bears a risk, too. Packagers could choose _either_ name to depend on. One
packager will use ell-devel out of consistency with other build requirements,
another will not even notice the virtual Provides and use "ell". And if you
wanted to submit a query on BuildRequires, you would need to consider all
available package names. Less convenient.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5DGa2roBhp&a=cc_unsubscribe