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

Re: Package separation/naming conventions

Le Sat, Sep 24, 2011 at 12:22:31PM +0200, Ole Streicher a écrit :
> Charles Plessy <plessy@debian.org> writes:
> >
> > although it looks ugly, perhaps you can consider calling your binary
> > packages libwcslib4, libwcslib-dev, libwcslib-doc and wcslib-util.  
> The first problem is that the library package should be called after its
> SONAME, and I dont want to change the SONAME because I would break the
> linking of existing programs. This is the reason why the library package
> is going to be called "libwcs4".
> For the -dev and -doc packages, I see no reason to add a second "lib" to
> their name: why "libwcslib" is better than "wcslib"? These names differ
> from the library SONAME anyway.

I think I am confused in what names you want to avoid, for which packages.  In

  * The name given at http://www.atnf.csiro.au/people/mcalabre/WCS/wcslib/ is
    wcslib.  That is a good name for your source package.

  * If libwcs4 matches the SONAME of your library, this is good.  If you think
    that the confusion with the other libwcs will induce people in wasting their
    time with the wrong package, then alternatives based on the source package's
    name, like wcslib or libwcslib, are possible.  The naming policy is a should
    that is to be everybody's advantage.  There can be good reasons to disregard
    a recommendation  (but I would recommend to documment them somewhere).

  * I think that it will make things simpler if the -dev package is named after
    the runtime package.  For instance libwcs4 / libwcs-dev.  This helps to
    quickly understand the relationship between a source package's build dependancies,
    and a binary package's depandancies.  I would find it confusing if building
    against barfoobaz-dev results in depending on libbarf instead of barfoobaz.

  * For -tools or -docs,  I think that the choice for the names isopen, but the
    best choices would be to append these suffixes to either the library's binary
    package name or the source package name.


Charles Plessy
Tsurumi, Kanagawa, Japan

Reply to: