Hi,
> > The library package guide should tell you to use
> >
> > libspf-1.0-0
>
> Note that the question was about the -dev package naming, which is
> not really explained in your excellent FAQ.
>
> PS: also, will you ever incorporate the shell script snippet by
> Steve Langasek I sent you, w
On 15.06.2005, at 01:51, Junichi Uekawa wrote:
The library package guide should tell you to use
If it doesn't, that's an error in the guide;
but I would also first check the SONAME of the library.
Exactly, but I do not recall that it mentions the name of the
corresponding dev package, but I d
also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.06.15.0151 +0200]:
> The library package guide should tell you to use
>
> libspf-1.0-0
Note that the question was about the -dev package naming, which is
not really explained in your excellent FAQ.
PS: also, will you ever incorporate the shel
Hi,
> A package that installs /usr/lib/libspf-1.0.so.0.0.0 should be names
> libspf-1.0-0 from all I can tell. The policy does not dictate how
> the -dev (and -doc) package should be named. I would prefer not to
> call it libspf-dev but rather encode the version.
>
> The library packaging guide s
also sprach Philipp Kern <[EMAIL PROTECTED]> [2005.06.14.1658 +0200]:
> Just looking it up in the old thread "Library package naming" I saw
> that you told me not to use -release at all when packaging a shared
> library.
Lol. Oh, *that* thread. :)
Yeah, I maintain
On 14.06.2005, at 14:47, martin f krafft wrote:
Do you have a pointer to the discussion?
Just looking it up in the old thread "Library package naming" I saw
that you told me not to use -release at all when packaging a shared
library. But yes, the naming of the dev package is not
also sprach Philipp Kern <[EMAIL PROTECTED]> [2005.06.13.2301 +0200]:
> If you see the -release bit as the API version you should name
> your dev package libspf-1.0-dev. That was at least what I was
> advised to do when I had the same problem some weeks ago.
Do you have a pointer to the discussi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 13.06.2005, at 22:36, martin f krafft wrote:
A package that installs /usr/lib/libspf-1.0.so.0.0.0 should be names
libspf-1.0-0 from all I can tell. The policy does not dictate how
the -dev (and -doc) package should be named. I would prefer not to
A package that installs /usr/lib/libspf-1.0.so.0.0.0 should be names
libspf-1.0-0 from all I can tell. The policy does not dictate how
the -dev (and -doc) package should be named. I would prefer not to
call it libspf-dev but rather encode the version.
The library packaging guide says I should incl
On Sun, May 08, 2005 at 09:49:38AM +0100, Neil Williams wrote:
> On Sunday 08 May 2005 12:20 am, Steve Langasek wrote:
> > On Sat, May 07, 2005 at 01:24:31PM +0100, Neil Williams wrote:
> > > Should I change the upstream version numbers of the existing library?
> > No, why would you do that? It's
On Sunday 08 May 2005 12:20 am, Steve Langasek wrote:
> On Sat, May 07, 2005 at 01:24:31PM +0100, Neil Williams wrote:
> > Should I change the upstream version numbers of the existing library?
>
> No, why would you do that? It's the package name that's wrong (confusing)
> here, not the library nam
On Sun, May 08, 2005 at 10:01:30AM +0200, martin f krafft wrote:
> also sprach Steve Langasek <[EMAIL PROTECTED]> [2005.05.08.0120 +0200]:
> > No, why would you do that? It's the package name that's wrong
> > (confusing) here, not the library name.
> I think I would disagree. Upstream has not rea
also sprach Steve Langasek <[EMAIL PROTECTED]> [2005.05.08.0120 +0200]:
> No, why would you do that? It's the package name that's wrong
> (confusing) here, not the library name.
I think I would disagree. Upstream has not read the libtool manual.
In short: do not use -release unless you are publis
On Sat, May 07, 2005 at 01:24:31PM +0100, Neil Williams wrote:
> > Setting aside any questions of how upstream *should* version their
> > libraries, here is a shell snippet that spits out the "best practices"
> > package name for any given library:
> > $ objdump -p /path/to/libfoo-bar.so.1.2.3 | s
also sprach Neil Williams <[EMAIL PROTECTED]> [2005.05.07.1424 +0200]:
> I've got my own package (with sponsor) to upload at some point but
> it depends on the current CVS version of an existing library. I'm
> a developer on that project (and co-maintainer) and I can change
> the upstream code. The
On Saturday 07 May 2005 11:34 am, Steve Langasek wrote:
> > When I read the Debian Library Packagaing Guide I get the impression
> > that libnet6-1-0 would be correct, but some in #debian-devel said
> > that the library is improperly named. Upstream's intention for â-
> > release 1â was that major
Hi Philipp,
On Sat, May 07, 2005 at 07:59:10AM +0200, Philipp Kern wrote:
> I got into trouble with library package naming. I package something
> called net6 which passes -release 1 and -version-info 0:0:0 to
> libtool. The library version number is 1.0, and the library on disk
&g
also sprach Philipp Kern <[EMAIL PROTECTED]> [2005.05.07.0759 +0200]:
> When I read the Debian Library Packagaing Guide I get the impression
> that libnet6-1-0 would be correct, but some in #debian-devel said
> that the library is improperly named.
Yes, it is. It should not mention -1. In fact
-BEGIN PGP SIGNED MESSAGE-
(BHash: SHA1
(B
(BDear mentors,
(B
(BI got into trouble with library package naming. I package something
(Bcalled net6 which passes -release 1 and -version-info 0:0:0 to
(Blibtool. The library version number is 1.0, and the library on disk
(Bis
Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
> I'm only parsing `debian/control.in' with sed, to add
> `-$(UPSTREAM_VERSION)' suffixes to the library packages names, so that
> they are always correctly versioned, so I can't see it causing
> problems, since the parsing is done within debian
Em 15 May 2002 20:55:42 +0100, Roger Leigh <[EMAIL PROTECTED]> escreveu:
> Junichi Uekawa <[EMAIL PROTECTED]> writes:
>
> > Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
> >
> > > One thing I'm not sure about are the Build-Depends. dpkg-genbuilddeps
> > > and 'dpkg-depcheck -b debian/rul
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
>
> > One thing I'm not sure about are the Build-Depends. dpkg-genbuilddeps
> > and 'dpkg-depcheck -b debian/rules build' both failed on my i386
> > (PIII) machine.
>
> pbuilder ?
I'm on a 56k dia
Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
> One thing I'm not sure about are the Build-Depends. dpkg-genbuilddeps
> and 'dpkg-depcheck -b debian/rules build' both failed on my i386
> (PIII) machine.
pbuilder ?
> Also, would anyone be willing to sponsor these packages while I am in
>
Roger Leigh <[EMAIL PROTECTED]> writes:
> Junichi Uekawa <[EMAIL PROTECTED]> writes:
>
> > Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
> >
> > > Would the following scheme be acceptable to you?:
> > >
> > > Package: libijs-0.34
> > > contains libijs-0.34.so
> >
> > Would those example
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes:
> On Mon, 06 May 2002, Roger Leigh wrote:
> > Is it common or good practice to keep the build for Debian separate
> > for upstream, or should I really get my changes incorporated upstream
> > first? It's just that I don't really see this ha
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
>
> > Would the following scheme be acceptable to you?:
> >
> > Package: libijs-0.34
> > contains libijs-0.34.so
>
> In my little testing, if I build a library with
> -export-dynamic -version-info
Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
> Would the following scheme be acceptable to you?:
>
> Package: libijs-0.34
> contains libijs-0.34.so
In my little testing, if I build a library with
-export-dynamic -version-info 0:0:0 -release 1.0.1
I get:
$ ls -1 .libs/
libdshconfig-1.0
On Mon, 06 May 2002, Roger Leigh wrote:
> Is it common or good practice to keep the build for Debian separate
> for upstream, or should I really get my changes incorporated upstream
> first? It's just that I don't really see this happening all that soon
> (it at all).
Go ahead and fork it, as lo
Roger Leigh <[EMAIL PROTECTED]> writes:
> The last three all use custom m4 macrocode I wrote (available in the
> ac-archive, renamed and specialised for use in ijs). Due to the
> unstable nature of the source, I defaulted to -release versioning, and
> disabling shared libraries by default, but t
hi
someone was suggesting to not provide shared libraries;
unfortunately this may create problems in the HPPA architecture:
indeed, it is not legal there to link portable (-fPIC) code with non
portable (afair); so , if someone else wants to build a shared
library that uses your library, then yo
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
>
> > However, the value of having a shared library at this point in time is
> > doubtful. gimp-print will Build-Depend on it, and possibly hpijs, but
> > I don't think there will be many other user
Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
> However, the value of having a shared library at this point in time is
> doubtful. gimp-print will Build-Depend on it, and possibly hpijs, but
> I don't think there will be many other users. I don't think that the
> effort of packaging it as
Robert Bihlmeyer <[EMAIL PROTECTED]> writes:
> Junichi Uekawa <[EMAIL PROTECTED]> writes:
>
> > I'd rather have shared libs with some Debian-specific
> > versioning than unversioned static library because it is easier to track
> > bugs on them, and fix them.
>
> The problem is that if upstream
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> I'd rather have shared libs with some Debian-specific
> versioning than unversioned static library because it is easier to track
> bugs on them, and fix them.
The problem is that if upstream gets "real" later and uses proper
versioning that may clash
Roger Leigh <[EMAIL PROTECTED]> immo vero scripsit:
> I have packaged libijs for Debian, but I'm not certain what package
> names to use. I can't see a clear answer from Debian Policy or
> current practice in Debian.
>
> For shared libraries, I would use libijs{n} and libijs-dev, but ijs
> does
>
> For shared libraries, I would use libijs{n} and libijs-dev, but ijs
> does not yet have a stable ABI, and is not versioned properly as well
> as being tiny, so I have just packaged it as a static library.
>
> Would 'ijs-dev' be legal (as in publib-dev), or should I use
> 'libijs-dev' (or is
Hello,
I have packaged libijs for Debian, but I'm not certain what package
names to use. I can't see a clear answer from Debian Policy or
current practice in Debian.
For shared libraries, I would use libijs{n} and libijs-dev, but ijs
does not yet have a stable ABI, and is not versioned properly
37 matches
Mail list logo
