Hi Benda,
Benda Xu writes:
> I am packaging a library called "casacore" which provides
>
> libcasa_python3.so.2 and libcasa_python.so.2
>
> with SONAME=2.
>
> How should them be named when the python major version and SONAME could
> cause confusion?
Since noone had a good idea here, I would pr
On 2016-05-11 22:13, Ole Streicher wrote:
> Christian Kastner writes:
>> On 2016-05-11 03:41, Benda Xu wrote:
>>> I am packaging a library called "casacore" which provides
>>> libcasa_python3.so.2 and libcasa_python.so.2
>>> with SONAME=2.
>>> How should them be named when the python major versi
Christian Kastner writes:
> On 2016-05-11 03:41, Benda Xu wrote:
>> I am packaging a library called "casacore" which provides
>> libcasa_python3.so.2 and libcasa_python.so.2
>> with SONAME=2.
>> How should them be named when the python major version and SONAME could
>> cause confusion?
> Accord
On 2016-05-11 03:41, Benda Xu wrote:
> Hi,
>
> I am packaging a library called "casacore" which provides
>
> libcasa_python3.so.2 and libcasa_python.so.2
>
> with SONAME=2.
>
> How should them be named when the python major version and SONAME could
> cause confusion?
>
> I can think of
>
>
Hi,
I am packaging a library called "casacore" which provides
libcasa_python3.so.2 and libcasa_python.so.2
with SONAME=2.
How should them be named when the python major version and SONAME could
cause confusion?
I can think of
libcasa2-python3 vs libcasa2-python
or
libcasa-python3-2 vs
Nico Schlömer writes:
> i.e., libraries with some number appended. What's the meaning of that
> number?
Hello Nico!
Those packages are shared libraries, and the number represents the
SOVERSION. Whenever the ABI of the shared library changes, the new
version should be in a binary package that ha
* Nico Schlömer , 2015-09-07, 20:46:
In Debian, I find packages such as
```
libzeep3.0
libzdb9
libzim0
```
i.e., libraries with some number appended. What's the meaning of that
number?
This is explained in Policy §8.1:
Normally, the run-time shared library and its ‘SONAME’ symlink should be
Hi everyone,
In Debian, I find packages such as
```
libzeep3.0
libzdb9
libzim0
```
i.e., libraries with some number appended. What's the meaning of that
number?
Cheers,
Nico
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 snipp
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
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
Dear Mentors,
On Sun, Apr 18, 2004 at 11:23:03AM +0200, GCS <[EMAIL PROTECTED]> wrote:
> I am intend to contine Martin F. Krafft's work on Grsecurity[1],
s/contine/continue/ and for making the life easier for Sponsors and
Mentors, I have uploaded both kernel-patch-2.4-grsecurity and
kernel-patch
Dear Mentors,
I am intend to contine Martin F. Krafft's work on Grsecurity[1], I have
filed an ITA[2] for this. I already released a new version as upstream
release is available, it's available via web[3] or apt[4]. However
upstream states that the old (1.9.x) version support is deprecated as
the
Dear Mentors,
On Sun, Apr 18, 2004 at 11:23:03AM +0200, GCS <[EMAIL PROTECTED]> wrote:
> I am intend to contine Martin F. Krafft's work on Grsecurity[1],
s/contine/continue/ and for making the life easier for Sponsors and
Mentors, I have uploaded both kernel-patch-2.4-grsecurity and
kernel-patch
Dear Mentors,
I am intend to contine Martin F. Krafft's work on Grsecurity[1], I have
filed an ITA[2] for this. I already released a new version as upstream
release is available, it's available via web[3] or apt[4]. However
upstream states that the old (1.9.x) version support is deprecated as
the
> > Question is, how should I call these packages? ccze-perl and
> > ccze-slang, or libccze-perl and libccze-slang? Or something completely
> > different? (If someone says ccze-foo1 and -foo2, I'm going to rip his
> > hands off :P)
>
> I would suggest ccze-perl and ccze-slang. (Isn't libfoo-perl
> > Question is, how should I call these packages? ccze-perl and
> > ccze-slang, or libccze-perl and libccze-slang? Or something completely
> > different? (If someone says ccze-foo1 and -foo2, I'm going to rip his
> > hands off :P)
>
> I would suggest ccze-perl and ccze-slang. (Isn't libfoo-perl
Hello,
On Tue, Mar 04, 2003 at 11:04:29AM +0100, Gergely Nagy wrote:
> I am a bit unsure about how to name two upcoming packages of mine, and
> wouldn't mind a few suggests :)
> So, I have this one package (ccze), which is extensible via plugins,
> and I have two, separately maintained, extensio
Hello,
On Tue, Mar 04, 2003 at 11:04:29AM +0100, Gergely Nagy wrote:
> I am a bit unsure about how to name two upcoming packages of mine, and
> wouldn't mind a few suggests :)
> So, I have this one package (ccze), which is extensible via plugins,
> and I have two, separately maintained, extensio
Hi!
I am a bit unsure about how to name two upcoming packages of mine, and
wouldn't mind a few suggests :)
So, I have this one package (ccze), which is extensible via plugins,
and I have two, separately maintained, extensions: one for running
perl scriptlets, and another for running slang scriptl
Hi!
I am a bit unsure about how to name two upcoming packages of mine, and
wouldn't mind a few suggests :)
So, I have this one package (ccze), which is extensible via plugins,
and I have two, separately maintained, extensions: one for running
perl scriptlets, and another for running slang scriptl
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
Thank you Julian for that complete summary. I can't think of any other
questions or scenarios to ask about.
Regards,
--
-- Grant Bowman <[EMAIL PROTECTED]>
* Julian Gilbey <[EMAIL PROTECTED]> [011128 16:06]:
> (1) libdb: Shared library packages have the major
Thank you Julian for that complete summary. I can't think of any other
questions or scenarios to ask about.
Regards,
--
-- Grant Bowman <[EMAIL PROTECTED]>
* Julian Gilbey <[EMAIL PROTECTED]> [011128 16:06]:
> (1) libdb: Shared library packages have the majo
On Wed, Nov 28, 2001 at 11:50:11AM -0800, Grant Bowman wrote:
> Hello,
>
> I have seen packages change their package names to include a version
> number. Reading the policy, there is little guidance on this subject.
> It would seem that's what Epochs are designed for. However I am aware
> there
On Wed, Nov 28, 2001 at 11:50:11AM -0800, Grant Bowman wrote:
> Hello,
>
> I have seen packages change their package names to include a version
> number. Reading the policy, there is little guidance on this subject.
> It would seem that's what Epochs are designed for. However I am aware
> ther
Hello,
I have seen packages change their package names to include a version
number. Reading the policy, there is little guidance on this subject.
It would seem that's what Epochs are designed for. However I am aware
there could be reasons for wanting to change the package name. One
reason mig
Hello,
I have seen packages change their package names to include a version
number. Reading the policy, there is little guidance on this subject.
It would seem that's what Epochs are designed for. However I am aware
there could be reasons for wanting to change the package name. One
reason mi
>> "DIL" == David I Lehn <[EMAIL PROTECTED]> writes:
[...]
> So does this mean the library is not suitable for Debian? Other
> projects use liba52 code, libac3 code (old version), or other
> implementations of the specs: xine, mplayer, xmps, videolan, avifile,
> and probably many more. Many of
* Christian Marillat <[EMAIL PROTECTED]> [20011019 15:50]:
> >> "DIL" == David I Lehn <[EMAIL PROTECTED]> writes:
> > I packaged liba52 and libmpeg2 a while ago. They've been sitting at
> > http://gstreamer.net/releases/debian/ (along with gstreamer debs too).
> > I'm still in limbo in the new mai
>> "DIL" == David I Lehn <[EMAIL PROTECTED]> writes:
> Hi,
hi,
> I packaged liba52 and libmpeg2 a while ago. They've been sitting at
> http://gstreamer.net/releases/debian/ (along with gstreamer debs too).
> I'm still in limbo in the new maintainer queue and figure I should ITP
> this stuff, up
>> "DIL" == David I Lehn <[EMAIL PROTECTED]> writes:
[...]
> So does this mean the library is not suitable for Debian? Other
> projects use liba52 code, libac3 code (old version), or other
> implementations of the specs: xine, mplayer, xmps, videolan, avifile,
> and probably many more. Many of
* Christian Marillat <[EMAIL PROTECTED]> [20011019 15:50]:
> >> "DIL" == David I Lehn <[EMAIL PROTECTED]> writes:
> > I packaged liba52 and libmpeg2 a while ago. They've been sitting at
> > http://gstreamer.net/releases/debian/ (along with gstreamer debs too).
> > I'm still in limbo in the new ma
"David I. Lehn" <[EMAIL PROTECTED]> writes:
> liba52-dev
> liba52-0
> libmpeg2-dev
> libmpeg2-0
Looks fine to me. Policy 11.3 would recommend that the packages be
called liba520 etc. without the dash, but unless my reading is wrong
this is not a strict requirement. Clarity would dictate the use o
>> "DIL" == David I Lehn <[EMAIL PROTECTED]> writes:
> Hi,
hi,
> I packaged liba52 and libmpeg2 a while ago. They've been sitting at
> http://gstreamer.net/releases/debian/ (along with gstreamer debs too).
> I'm still in limbo in the new maintainer queue and figure I should ITP
> this stuff, u
"David I. Lehn" <[EMAIL PROTECTED]> writes:
> liba52-dev
> liba52-0
> libmpeg2-dev
> libmpeg2-0
Looks fine to me. Policy 11.3 would recommend that the packages be
called liba520 etc. without the dash, but unless my reading is wrong
this is not a strict requirement. Clarity would dictate the use
Hi,
I packaged liba52 and libmpeg2 a while ago. They've been sitting at
http://gstreamer.net/releases/debian/ (along with gstreamer debs too).
I'm still in limbo in the new maintainer queue and figure I should ITP
this stuff, update it, and get it in the archives.
I'm unsure what to do about the
Hi,
I packaged liba52 and libmpeg2 a while ago. They've been sitting at
http://gstreamer.net/releases/debian/ (along with gstreamer debs too).
I'm still in limbo in the new maintainer queue and figure I should ITP
this stuff, update it, and get it in the archives.
I'm unsure what to do about th
On Tue, Jul 03, 2001 at 11:37:33AM +0200, peter karlsson wrote:
> Can a single binary package have a different name than the source package
> it comes from?
Yes, it can.
> I am packaging the LysKOM tty-client, which has the upstream name
> tty-client, but I have received requests for renaming the
On Tue, Jul 03, 2001 at 11:37:33AM +0200, peter karlsson wrote:
> Can a single binary package have a different name than the source package
> it comes from?
Yes, it can.
> I am packaging the LysKOM tty-client, which has the upstream name
> tty-client, but I have received requests for renaming th
Hi!
Can a single binary package have a different name than the source package it
comes from?
I am packaging the LysKOM tty-client, which has the upstream name
tty-client, but I have received requests for renaming the Debian package to
lyskom-tty-client. Can I do that without changing the name of
Hi!
Can a single binary package have a different name than the source package it
comes from?
I am packaging the LysKOM tty-client, which has the upstream name
tty-client, but I have received requests for renaming the Debian package to
lyskom-tty-client. Can I do that without changing the name of
On Thu, 15 Feb 2001, Ingo Saitz wrote:
> MoiN
>
> On Mon, Feb 12, 2001 at 04:30:32PM +0100, Ove Kaaven wrote:
> > Are there any docs with guidelines on package naming?
>
> See the packaging manual, Section 11.3.
There's no such section in the packaging manual. But
On Thu, 15 Feb 2001, Ingo Saitz wrote:
> MoiN
>
> On Mon, Feb 12, 2001 at 04:30:32PM +0100, Ove Kaaven wrote:
> > Are there any docs with guidelines on package naming?
>
> See the packaging manual, Section 11.3.
There's no such section in the packaging manual. But
MoiN
On Mon, Feb 12, 2001 at 04:30:32PM +0100, Ove Kaaven wrote:
> Are there any docs with guidelines on package naming?
See the packaging manual, Section 11.3.
> The build process gives me
> libmk4.so.0.0.0, libmk4tcl.so.0.0.0, and optionally libmk4py.so.0.0.0
So your package should
MoiN
On Mon, Feb 12, 2001 at 04:30:32PM +0100, Ove Kaaven wrote:
> Are there any docs with guidelines on package naming?
See the packaging manual, Section 11.3.
> The build process gives me
> libmk4.so.0.0.0, libmk4tcl.so.0.0.0, and optionally libmk4py.so.0.0.0
So your package
On Mon, Feb 12, 2001 at 04:21:00PM -0800, Mike Markley wrote:
> IMO the best name is the one that does the best job of expressing what it's
> called without being so generic as to cause potential name conflict. I'd
> personally go with libmetakit, with -dev, -tcl, -python if you split it up.
> In g
On Mon, Feb 12, 2001 at 04:21:00PM -0800, Mike Markley wrote:
> IMO the best name is the one that does the best job of expressing what it's
> called without being so generic as to cause potential name conflict. I'd
> personally go with libmetakit, with -dev, -tcl, -python if you split it up.
> In
unless there's some
pressing need to be able to install multiple versions at the same time, so
hopefully libmetakit4 or 40 won't be necessary.
On Mon, Feb 12, 2001 at 04:30:32PM +0100, Ove Kaaven <[EMAIL PROTECTED]> spake
forth:
> Are there any docs with guidelines on packag
unless there's some
pressing need to be able to install multiple versions at the same time, so
hopefully libmetakit4 or 40 won't be necessary.
On Mon, Feb 12, 2001 at 04:30:32PM +0100, Ove Kaaven <[EMAIL PROTECTED]> spake forth:
> Are there any docs with guidelines on packag
Are there any docs with guidelines on package naming? I need to package
some dependencies, one of which is the MetaKit portable embedded database
library (http://www.equi4.com/metakit/). The build process gives me
libmk4.so.0.0.0, libmk4tcl.so.0.0.0, and optionally libmk4py.so.0.0.0
(they don&#
Are there any docs with guidelines on package naming? I need to package
some dependencies, one of which is the MetaKit portable embedded database
library (http://www.equi4.com/metakit/). The build process gives me
libmk4.so.0.0.0, libmk4tcl.so.0.0.0, and optionally libmk4py.so.0.0.0
(they don&#
On Tue, Dec 14, 1999 at 01:25:09AM +, Peter Maydell wrote:
> What should you do if the upstream tarball includes ick like FIFOs,
> random junk files and binaries? I tried just using the true upstream
> tarball but dpkg-buildpackage took exception both to the FIFO in the
> upstream source and to
On Mon, Dec 13, 1999 at 02:13:39PM +, Chris Rutter wrote:
> On Mon, 13 Dec 1999, Hamish Moffatt wrote:
>
> > As Antti-Juhani says, use lowercase. It doesn't matter what directory
> > the .orig.tar.gz unpacks to; dpkg-source will cope. Don't extract it,
> > rename it, and recreate the .orig.tar
Chris Rutter wrote:
> On Mon, 13 Dec 1999, Hamish Moffatt wrote:
>
> > As Antti-Juhani says, use lowercase. It doesn't matter what directory
> > the .orig.tar.gz unpacks to; dpkg-source will cope. Don't extract it,
> > rename it, and recreate the .orig.tar.gz just to fix the directory name;
> >
On Mon, 13 Dec 1999, Hamish Moffatt wrote:
> As Antti-Juhani says, use lowercase. It doesn't matter what directory
> the .orig.tar.gz unpacks to; dpkg-source will cope. Don't extract it,
> rename it, and recreate the .orig.tar.gz just to fix the directory name;
> it's better to use "pristine sourc
On Mon, Dec 13, 1999 at 03:23:28AM +, Chris Rutter wrote:
> I'm slightly mystified, in my newsbieship, as to what this means.
>
> The source archive is `mLib-1.6.1.tar.gz', and it unpacks into a directory
> called `mLib-1.6.1'. I suppose `dpkg-source' is supposed to rename that
> to `mlib-1.6
[ -devel dropped from distribution list ]
On Mon, Dec 13, 1999 at 03:23:28AM +, Chris Rutter wrote:
> Now; I was under the impression that all package names had to be lowercase;
> i.e. I would be uploading `libmlib1' and `libmlib-dev'. However, in
> section 4.2.1 of v3.1.0.0 of the Debian Pac
I'm packaging mLib[1], a library much like `glib'.
Now; I was under the impression that all package names had to be lowercase;
i.e. I would be uploading `libmlib1' and `libmlib-dev'. However, in
section 4.2.1 of v3.1.0.0 of the Debian Packaging Manual:
4 Control files and their fields
[
92 matches
Mail list logo
