[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: creating libraries



On Thu, Apr 01, 1999 at 08:08:02AM +0100, Pedro Guerreiro wrote:
> > Yes, GTK+ is not libgtk1. Yes, XForms is not libforms0.88. Yes, FLTK is
> > not libfltk1. Yes, GGI is not libggi2. Yes, ncurses is not libncurses4.
> > Yes, PAM is not libpam0. Yes, PropList is not libproplist0. Yes, ReadLine
> > is not libreadline2.
> 
> Don't need to came so hard, I was just making a question (and a good one too,
> IMHO :-) ).

Sorry :)

> I've read, re-read, tri-read, ... and still don't quite get it.
> I says there that the library should be called <libraryname><soname>, but that
> is not the same as lib<name><soname>, or is it? 
> 
> Ok, just let me make clear that I don't have any problem making the library
> name libcgraph instead of just cgraph, I just want to make a point. 
> I can see that the _normal_ way to build the libraries these
> days is to use lib<name><soname>, and all the new stuff is following these
> paths, as one can see by the examples you give above _but_, as I read it, the
> Debian Policy _does not_ makes you do so.
> 
> How about changing the policy to make this fact perfectly clear? If we replace
> <libraryname><soname> by lib<name><soname> then there should be no more doubts
> to anyone.

Indeed, it can get confusing. But if you look at the filename, the
library file name is libcgraph. The extensions are .so and .1.
It makes sense, at least to me. Anyhow, send this suggestion to
debian-policy list.

> > Yes, that is the problem, actually, because you usually need to have a
> > good reason to have a virtual package. Better ask on debian-devel.
> 
> I don't think it's worth the trouble. I _don't_ have a good reason to create a
> virtual package. The library is pretty much useable and stable.

Come to think of it, I should go and file a bug against dh-make about
this. New packages shouldn't make new virtual packages by default.

-- 
enJoy -*/\*- http://jagor.srce.hr/~jrodin/


Reply to: