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... 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_d...

...

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

On Thu, Nov 08, 2012 at 11:23:25AM +0100, Dominique Leuenberger a.k.a DimStar wrote:

Quoting Michal Vyskocil :

...

Are you refer to

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

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.

Actually, this is not entirely correct I think: IF -devel packages can be installed in multiple versions, then the number usually does NOT co-incide with the soname... $NUM of the library is being bumped on ABI incompatibility... the versions in the -devel package usually refer to a API level... in now way should/must they be linked.

On this case, it's more useful to follow the API NUM specification, which is usually also represented in the directory layout used in %{_includedir}

http://tinyurl.com/cxltnss

Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Nov 08, 2012 at 02:48:40PM +0100, Michael Matz wrote:

Hi,

On Thu, 8 Nov 2012, Michal Vyskocil wrote:

...

I hope I did not delete any code, just try to better structure it to be not like a law, but something more understandable.

Actually a policy should really read like a law. Rationales and explanations can go on either extra pages, or at least extra sections after the rules are written down.

...

...

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).

Yes, of course, such scheme can be part of best practices indeed.

OK then I'll create best practices page "for dummies", which will link to the existing page. Regards Michal Vyskocil