Mailinglist Archive: opensuse-packaging (266 mails)

< Previous Next >
Re: [opensuse-packaging] Make Shared Library Policy easier to read and follow
On Wed, Nov 07, 2012 at 04:14:01PM +0100, Michael Matz wrote:
Hi,

Hi Michael,

On Wed, 7 Nov 2012, Michal Vyskocil wrote:

I consider the Shared Library Policy as a bad structured and writted
document, so I've decided to restructure to be more readable and give
the needed information on the begining. Or to reduce crufty sections,
like exceptions and so.

Well, you also removed an important part, when -devel packages need to be
versioned.

Are you refer to

http://en.opensuse.org/User:Mvyskocil/Shared_library_packaging_policy#-devel_packages

If more than one version of a -devel package can be installed at the
same time (for example because includes are packaged in a versioned
directory and shared libraries have a versioned name like
libgtk1.so.1), the -devel packages should be suffixed with a number
that allows identifying the version of the library (usually this is the
same number as the shared library package suffix $NUM). So such a
-devel package would be named lib$NAME$NUM-devel.

I hope I did not delete any code, just try to better structure it to be
not like a law, but something more understandable. If if did so, then
it's a definitelly a bug.


My attempt is here
http://en.opensuse.org/User:Mvyskocil/Shared_library_packaging_policy

For the most part I like the current version better, sorry. I do agree,
though, that the libtool section (or better the whole "Versioning schemes"
section) has no real place in the policy page. This page is about policy,
not about explaining at large how to derive shared library versions. It
should be moved to some other wiki page.

Makes a sense


The current Elibility section is completely off. Its second point as
written is plain wrong.

It has been moved, but I did not touch it

http://en.opensuse.org/User:Mvyskocil/Shared_library_packaging_policy#What_does_not_belongs_to_versioned_package


Should be moved to appropriate place in the document, but in overall I
see it as a better version if the original, because it try to explain
all aspects from the begining. That includes the name of source package,
devel package and so.

A policy page should list the policy first, preferably in clear and easily
verifyable rules. If rationales are provided at all, they should come
_after_ the policy.

Sure, but the problem is the policy is full of in case if, but there is
an exception, see foo bar for more. So it is more like a lawyer text,
than something people will want to read and follow.

If anyone will rewrite out policy to few simple points, I'd be happy,
but I must say I failed to do so :-(

What about make policy first, but emphasise the examples from the
beginning? Or maybe split the policy pages and an examples, but I doubt
it will improve the readibility.


But there is the unclear point (and I blame the structure of the policy)
- the name of the devel package. The zlib example uses the zlib-devel
($source-devel), which might be the prefered form.

The policy doesn't try to enforce any naming scheme on the base part of
the -devel package. It's simply out of scope for it. I don't see the
need to include any rules. The rules for naming shared libraries have
technical reasons (in order to enforce disjoint rpm names), there are no
technical reasons to name the base name of -devel packages in any
particular way.

I'd say it makes a sense to at least _recommend_ the naming of the other
parts (even the -devel package is not really important, as we have now
pkgconfig(foo) symbols). Sure, there is no technical reason to not have
libz1-devel. On the other hand using the same scheme makes out
distribution more consistent and less surprising for people deal with
foreign packages.

Thanks for the feedback
Michal Vyskocil
< Previous Next >