On Fri, Nov 20, 2015 at 10:24:09AM +, Jonathan Dowland wrote:
> Is there anything preventing a rename of libpcre2-dev to libpcre-dev, first?
That should, of course, have been
"Is there anything preventing a rename of libpcre3-dev to libpcre-dev, first?"
On Wed, Oct 28, 2015 at 03:51:26PM +, Matthew Vernon wrote:
> No, the -dev packages will need to be co-installable, too. I expect
> we'll need to ship PCRE (including its -dev package) for quite some time.
>
> ...so I'm still not sure what to call PCRE2 :-/
Sorry if I'm being thick, but libpc
On 10/22/2015 10:47 AM, Matthew Vernon wrote:
The natural thing to call the PCRE2 packages is pcre2, but that's going
to lead to confusion - ISTM that something that makes it clear that
PCRE2 is newer than PCRE is desirable. And, obviously, PCRE & PCRE2 need
to be co-installable.
There are alre
Matthew Vernon writes:
> No, the -dev packages will need to be co-installable, too. I expect
> we'll need to ship PCRE (including its -dev package) for quite some time.
> ...so I'm still not sure what to call PCRE2 :-/
It's pretty ugly, but I'd tend to use libpcre-v2-dev. Hopefully people
will
Hi,
Simon Richter writes:
> Hi Matthew,
>
> On 22.10.2015 16:47, Matthew Vernon wrote:
>
> > Upstream has a new PCRE library, which they hope everyone will
> > eventually migrate to, which is called PCRE2. It is currently version
> > 10.20. It ships things named like libpcre2-8.so.0, and its p
Hi Matthew,
On 22.10.2015 16:47, Matthew Vernon wrote:
> Upstream has a new PCRE library, which they hope everyone will
> eventually migrate to, which is called PCRE2. It is currently version
> 10.20. It ships things named like libpcre2-8.so.0, and its pcregrep is
> called pcre2grep.
That should
Hi,
PCRE has been in Debian for some time; the current packages correspond
to upstream 8.35 (with a pile of backported security fixes, which I hope
will end up as an 8.38 release some time soon). These packages are
called pcre3 (and libpcre3 ships libpcre.so.3).
Upstream has a new PCRE library, w
On Apr 26, Mike Markley <[EMAIL PROTECTED]> wrote:
> Is it more confusing to have the package name differ by one letter from
> the only binary in it, or is it more confusing for the package to be
> named via a different convention than similar applications? Any input is
> appreciated.
Probably it
It has been suggested to me that I get some input from the list on the
naming of my recently uploaded packages for dkim-milter and dk-milter.
I thought I had opened an ITP for this purpose, but it turns out I had
not; hence this message.
The core issue: Upstream calls the *packages* dkim-milter an
Alexander Petrov gmail.com> wrote:
> I think naming default version 'sim-kde' is wrong, because the name is
> not intuitive to a user, who just wants to have an IM installed, and
> who doesn't want to bother with libraries used by the program
Now that I think of it that way, I take back my previo
im-qt?
Why not name it sim-qt-only or -nokde like gnuplot-nox.
ok, as I understand package naming - is just a question of personal
preference and there is no established policy on that.
will name them sim and sim-qt.
Regards, Jörg.
--
Thanks.
--
BR. Alexander 'zowers' Petrov.
Hi Alexander,
Alexander Petrov <[EMAIL PROTECTED]> wrote:
> On 7/3/06, Jason Spiro <[EMAIL PROTECTED]> wrote:
>> > The package is compiled with kde libraries. Users demand to create one
>> > more binary package - compiled with qt only.
>> > I would like to use 'sim' package name for kde version an
Alexander Petrov wrote:
> Hello,
>
> I maintain sim package - Simple Instant Messenger, http://sim-im.org/ .
> The package is compiled with kde libraries. Users demand to create one
> more binary package - compiled with qt only.
> I would like to use 'sim' package name for kde version and 'sim-qt
Hello
On 7/3/06, Jason Spiro <[EMAIL PROTECTED]> wrote:
> The package is compiled with kde libraries. Users demand to create one
> more binary package - compiled with qt only.
> I would like to use 'sim' package name for kde version and 'sim-qt'
> for qt-only version.
I am a newbie here, but I a
Le 03-07-2006, Alexander Petrov <[EMAIL PROTECTED]> a écrit :
> Hello,
>
> I maintain sim package - Simple Instant Messenger, http://sim-im.org/ .
> The package is compiled with kde libraries. Users demand to create one
> more binary package - compiled with qt only.
> I would like to use 'sim' pa
Hello,
I maintain sim package - Simple Instant Messenger, http://sim-im.org/ .
The package is compiled with kde libraries. Users demand to create one
more binary package - compiled with qt only.
I would like to use 'sim' package name for kde version and 'sim-qt'
for qt-only version.
Is it ok?
--
On 29-Jul-05, 08:50 (CDT), GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
> Exercise: let's say I have an application that uses GSSAPI, and has to
> be able to be built statically. Requirements:
>
> - It should build with Heimdal's libgs
On Thu, Jul 28, 2005 at 02:18:29PM -0400, Jay Berkenbilt wrote:
> > FWIW, detecting a fixed libtool would be rather difficult, since it's the
> > libtool used by the depending application which does the recursion and
> > therefore needs to be fixed.
> I was thinking we'd be able to tell from the .
> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:
>> fact 3: libtool library libtool tries to implement a wrapper
>> around shared library and static library, so that both of them
>> can be uniformly processed, and allows specifying just: libtool
>> cc -lnewt a.c
St
On Fri, Jul 29, 2005 at 12:06:38PM -0400, Jay Berkenbilt wrote:
> This is nice, but I think it's not really very autoconfish [tm] in
> spirit.
It is not meant to be autoconfish. It is meant to be run _before_
configure, so you can decide if you have to re-libtoolize the package or
not.
> Also, t
GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
>
>> I'd think we could come up with a way to detect the version of libtool
>> in use, somehow. :)
>
> LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
> LTMAIN_SH_PATH="${LTMAIN_SH_PAT
On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
> I'd think we could come up with a way to detect the version of libtool
> in use, somehow. :)
LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
LTMAIN_SH_PATH="${LTMAIN_SH_PATH:-.}"
grep ^VERSION "$LTMAIN_SH_PATH"/ltmain.sh |
On Thu, Jul 28, 2005 at 07:05:34AM -0400, Stephen Frost wrote:
> We've had that discussion before. Last I recall there wasn't really a
> huge fight to keep them.
Well, Debian developers do not really need them. But there are people
who do not develop Debian but develop other software _using_ Deb
On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
> Why is this better? I have to change my perfectly normal, standard Unix
> link command to use something that completely hides the actual link
> command and makes debugging problems nearly impossible?
Exercise: let's say I have an
Steve Langasek <[EMAIL PROTECTED]> writes:
> I think static libs have outlived their usefulness in Debian for the
> most part; but using this to justify creating whole *new* packages for
> static linking would just be insane. The dependencies of -dev packages
> are just not that big a deal to war
On Fri, Jul 29, 2005 at 07:06:34AM +0900, Junichi Uekawa wrote:
> > > - Don't ship .la files in the -dev package; don't depend on any other -dev
> > > packages except those whose headers you need. This gives optimal
> > > results
> > > for shared linking by pruning all unnecessary build-depen
Hi,
> > - Don't ship .la files in the -dev package; don't depend on any other -dev
> > packages except those whose headers you need. This gives optimal results
> > for shared linking by pruning all unnecessary build-dependencies and
> > dependencies; but it also screws over anyone trying to
Steve Langasek <[EMAIL PROTECTED]> wrote:
> It doesn't exist; I think it's a great idea. Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?
Sounds good to me.
I'm going to be leaving my current job in a few weeks and taking
several weeks off between jobs. I
On 28-Jul-05, 03:02 (CDT), Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> fact 1: shared library
>
> gcc -lnewt a.c
Right. No problem.
> fact 2: static library
>
> gcc -lslang -lnewt a.c
Right, Just like it's always been on Unix systems.
> fact 3: libtool library
> libtool tries to impleme
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> It doesn't exist; I think it's a great idea. Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?
This sounds reasonable to me; I appriciate that it's a libtool-specific
thing and not a blanket policy. :)
> FWIW, de
On Thu, Jul 28, 2005 at 08:29:52AM -0400, Jay Berkenbilt wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > - Leave the .la files in place; -dev packages need to depend on -dev
> > packages corresponding to those runtime dependencies that are also built
> > using libtool. This is the stat
Steve Langasek <[EMAIL PROTECTED]> wrote:
> - Leave the .la files in place; -dev packages need to depend on -dev
> packages corresponding to those runtime dependencies that are also built
> using libtool. This is the status quo.
If we do this (which I think we should for now), I would sugges
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > - Option 4 (requires volunteers): fix libtool
>
> Blankly stating that libtool needs to be 'fixed'
> because it is 'broken' is not very helpful.
> Would you care to explain what needs to be fixed and why
> it is broken? Good working examples would
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> > * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > > libtool is broken in this regard and needs to be fixed to survive
Hi,
> > - Kill the .la files and .a files. Drop support for static linking. Not
> > something that should be done lightly and without prior project-wide
> > discussion.
> > - Leave the .la files in place; -dev packages need to depend on -dev
> > packages corresponding to those runtime depe
On Wed, Jul 27, 2005 at 10:16:54PM -0400, Josh Metzler wrote:
> On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
> > But ok, yes, that is an option; let's spell the options out completely:
> >
> > - Don't ship .la files in the -dev package; don't depend on any other
> > -dev packages excep
On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
> But ok, yes, that is an option; let's spell the options out completely:
>
> - Don't ship .la files in the -dev package; don't depend on any other
> -dev packages except those whose headers you need. This gives optimal
> results for shared
On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > libtool is broken in this regard and needs to be fixed to survive
> > > missing files.
> > Then fix it instead of gi
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > libtool is broken in this regard and needs to be fixed to survive
> > missing files.
>
> Then fix it instead of giving people bad advice.
Do you actually have anything beyond "libtool
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > 4. -dev packages should depend on other -dev packages?
> > Yes.
> Whoah, whoah, whoah. This is just blatently false. There *certainly*
> wasn't a consensus that -dev packages should regularly depend on -dev
> pacakges. There'
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> 1. Conclusion:
> For the initial question of
> 'How does one decide which -dev package accompanies
> runtime library package'
> There is no answer, and we have not reached the consensus.
It would be possible to put forth a proposal to deal with
Hi,
Since I've started up this thread, I'd like to summarize what was
discussed in this thread.
1. Conclusion:
For the initial question of
'How does one decide which -dev package accompanies
runtime library package'
There is no answer, and we have not reached the consensus.
2. Methods to
Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> > > 2. The information of -dev packages depending on other -dev packages
> > > cannot be automatically determined currently;
> > > it should be possible to obtain a minimal list by analyzing the
> > > NEEDED field of the objdump output.
> >
> > Errr, -
On 7/15/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
> > An alternate solution is to have a database for that kind of thing,
> > but I forsee that it requires effort to maintain and keep up-to-date.
>
> Like the database I just que
On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
> > > Having a solid naming scheme will allow me to
> > > ldd /usr/lib/libwhatever.so to track down its
> > > shared library dependency, and appending "-dev"
> > > to individual package to create the list of
> > > requisite -dev pac
On Fri, Jul 15, 2005 at 05:18:23PM +0900, Junichi Uekawa wrote:
> > > BTW, having Build-Depends: libfoo-dev in
> > > a library's build-deps, will allow the developer
> > > to overlook a soname change in depending shared library.
> > > Which is a bad idea in the QA standpoint.
> > Yes and no.
> >
> Stephen's points are valid and quite useful
> considering an upstream developer's point of view,
> but for random user joe who is trying to find a development
> package, one of the following may help him find the right package
Joe user should do:
apt-cache search libNAME dev
(or use synaptic,
On Fri, Jul 15, 2005 at 10:44:04PM +0900, Junichi Uekawa wrote:
> Stephen's points are valid and quite useful
> considering an upstream developer's point of view,
> but for random user joe who is trying to find a development
> package, one of the following may help him find the right package
>
>
Hi,
Thanks for your time and feedback. I appreciate it very much.
> You could also suggest a policy for libs to have a libfoo.devname file
> similar to the libfoo.shlibs file but naming the needed -dev
> packages. If that is a good idea or not you have to think about. Just
> a wild idea.
Yes, t
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Hi,
>
>> > Having a solid naming scheme will allow me to
>> >
>> > ldd /usr/lib/libwhatever.so to track down its
>> > shared library dependency, and appending "-dev"
>> > to individual package to create the list of
>> > requisite -dev packages.
You c
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Hi,
>
>> > BTW, having Build-Depends: libfoo-dev in
>> > a library's build-deps, will allow the developer
>> > to overlook a soname change in depending shared library.
>> > Which is a bad idea in the QA standpoint.
>>
>> Yes and no.
>>
>> The program
* Francesco P. Lovergine ([EMAIL PROTECTED]) wrote:
> On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
> > also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.07.14.1416 +0300]:
> > > libfoobar-2.1-0 will have
> > > libfoobar-2.1-0-dev.
> >
> > Please distinguish between API and
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > If this is actually necessary for libtool-using packages, then write
> > something which goes through all of the .la files and does this, since
> > that's what libtool wants to do.
>
> and
>
> > Errr, you still havn't said what problem you're tryin
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > BTW, having Build-Depends: libfoo-dev in
> > > a library's build-deps, will allow the developer
> > > to overlook a soname change in depending shared library.
> > > Which is a bad idea in the QA standpoint.
> >
> > Yes and no.
> >
> > The program
On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
> also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.07.14.1416 +0300]:
> > libfoobar-2.1-0 will have
> > libfoobar-2.1-0-dev.
>
> Please distinguish between API and ABI!
>
True. Indeed the proposed policy is already followed in
Hi,
> > Having a solid naming scheme will allow me to
> >
> > ldd /usr/lib/libwhatever.so to track down its
> > shared library dependency, and appending "-dev"
> > to individual package to create the list of
> > requisite -dev packages.
>
> With the current scheme it is:
>
> ldd /usr/lib/libwh
Hi,
Thanks for your input.
> > Having a solid naming scheme will allow me to
> >
> > ldd /usr/lib/libwhatever.so to track down its
> > shared library dependency, and appending "-dev"
> > to individual package to create the list of
> > requisite -dev packages.
>
> If this is actually necessa
Hi,
> > BTW, having Build-Depends: libfoo-dev in
> > a library's build-deps, will allow the developer
> > to overlook a soname change in depending shared library.
> > Which is a bad idea in the QA standpoint.
>
> Yes and no.
>
> The programer can overlook the soname change for the source. The A
also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.07.14.1416 +0300]:
> libfoobar-2.1-0 will have
> libfoobar-2.1-0-dev.
Please distinguish between API and ABI!
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' :proud
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> BTW, having Build-Depends: libfoo-dev in
> a library's build-deps, will allow the developer
> to overlook a soname change in depending shared library.
> Which is a bad idea in the QA standpoint.
Yes and no.
The programer can overlook the soname chang
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Having a solid naming scheme will allow me to
>
> ldd /usr/lib/libwhatever.so to track down its
> shared library dependency, and appending "-dev"
> to individual package to create the list of
> requisite -dev packages.
With the current scheme it is:
Will Newton <[EMAIL PROTECTED]> writes:
> On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
>
>> The current recommendation I'm trying to give is:
>>
>> Package: libXXX-dev
>> Conflicts: libXXX-dev
>> Provides: libXXX-dev
>>
>>
>> Thus, it won't contradict with your requirement to
>> be ab
#include
* Will Newton [Thu, Jul 14 2005, 05:36:05PM]:
> > Thus, it won't contradict with your requirement to
> > be able to just build-depend on libXXX-dev.
>
> I may be wrong, but I thought it was incorrect to build-dep only on a pure
> virtual package? e.g.:
>
> Build-Depend: xlibmesa-gl-de
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> The current recommendation I'm trying to give is:
>
> Package: libXXX-dev
> Conflicts: libXXX-dev
> Provides: libXXX-dev
>
>
> Thus, it won't contradict with your requirement to
> be able to just build-depend on libXXX-dev.
Uhh, then it doesn't
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> BTW, having Build-Depends: libfoo-dev in
> a library's build-deps, will allow the developer
> to overlook a soname change in depending shared library.
> Which is a bad idea in the QA standpoint.
Uh, no it isn't. SONAME changes are fine, the package h
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > There may be other showstoppers.
> >
> > What does doing this solve? What does it even help with?
>
> Hmmm... we are talking about naming
> Debian development shareed library package names based on
> Debian runtime shared library package names.
Hi,
> You can (and it is often done) extend an api to include more
> functionality without breaking the existing api. Any program using one
> of the new functions must use a versioned depend on the libfoo-dev
> package introducing the function.
>
> The API can (and will) even stay compatibly acro
On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
> The current recommendation I'm trying to give is:
>
> Package: libXXX-dev
> Conflicts: libXXX-dev
> Provides: libXXX-dev
>
>
> Thus, it won't contradict with your requirement to
> be able to just build-depend on libXXX-dev.
I may be wron
Hi,
> > 2. The information of -dev packages depending on other -dev packages
> > cannot be automatically determined currently;
> > it should be possible to obtain a minimal list by analyzing the
> > NEEDED field of the objdump output.
>
> Errr, -dev packages generally don't (and shouldn't) depe
Hi,
> > I'd like to propose, for new -dev packages, to
> > name -dev packages after their runtime library counterparts.
>
> I personally found it very handy that the dev packages automatically
> selects the most recent API compatible version. Why do you want this
> switch by the way? You did not
Hi,
> > There may be other showstoppers.
>
> What does doing this solve? What does it even help with?
Hmmm... we are talking about naming
Debian development shareed library package names based on
Debian runtime shared library package names.
>
> > I would really like this 10-year old non-reg
[once more, doesn't belong on -release...]
On Thu, Jul 14, 2005 at 12:11:21PM -0400, Stephen Frost wrote:
> * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > > I'd like to propose, for new -dev packages, to
> > > > name -dev packages after their r
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Hi,
>
>> > I'd like to propose, for new -dev packages, to
>> > name -dev packages after their runtime library counterparts.
>> >
>> > If the library package is named lib$NAME,
>> > call the -dev package lib$NAME-dev.
>> [...]
>>
>> Hej,
>> The obvio
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > I'd like to propose, for new -dev packages, to
> > > name -dev packages after their runtime library counterparts.
> >
> > Uh, no? The -dev packages have no need to match to a specific runtime
> > li
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> There may be other showstoppers.
What does doing this solve? What does it even help with?
> I would really like this 10-year old non-regulation to
> go to a concensus (it is indeed rather embarassing we don't
> agree on a good solution after 10 yea
Hi,
> * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > I'd like to propose, for new -dev packages, to
> > name -dev packages after their runtime library counterparts.
>
> Uh, no? The -dev packages have no need to match to a specific runtime
> library and this just creates unnecessary work.
Well
Hi,
> > I'd like to propose, for new -dev packages, to
> > name -dev packages after their runtime library counterparts.
> >
> > If the library package is named lib$NAME,
> > call the -dev package lib$NAME-dev.
> [...]
>
> Hej,
> The obvious downside of this is that the name of dev-package will
On Thu, 2005-07-14 at 20:16 +0900, Junichi Uekawa wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
I personally found it very handy that the dev packages automatically
selects the most recent API compatible version. Why do you
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
Uh, no? The -dev packages have no need to match to a specific runtime
library and this just creates unnecessary work.
> This allows mechani
[I am stopping the cross-posting to -release, as -release is no
discussion list]
On 2005-07-14 Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
>
> If the library package is named lib$NAME,
>
Hi,
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
If the library package is named lib$NAME,
call the -dev package lib$NAME-dev.
For example,
libxxx0 will have
libxxx0-dev.
libfoobar-2.1-0 will have
libfoobar-2.1-0-dev.
This
On Tue, Jun 03, 2003 at 03:25:15PM +0200, Mario Lang wrote:
> Sure, the epoch is of course necessary. What I am wondering about is how
> katie will react if a source package is uploaded which produces a binary
> package which is already produced by another source package.
>
> I.e., is there any t
"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Mon, Jun 02, 2003 at 03:15:19PM -0400, Deedra Waters wrote:
>
> > I've been working on the package "kernel-patch-speakup" which has a
> > source package called speakup-cvs and produces the binary called
> > kernel-patch-speakup_2002
Hi,
On Mon, Jun 02, 2003 at 03:15:19PM -0400, Deedra Waters wrote:
> I've been working on the package "kernel-patch-speakup" which has a
> source package called speakup-cvs and produces the binary called
> kernel-patch-speakup_20021221-1_all.deb, well, there is a stable
> version of speakup t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been working on the package "kernel-patch-speakup" which has a source
package called speakup-cvs and produces the binary called
kernel-patch-speakup_20021221-1_all.deb, well, there is a stable version
of speakup that I'd like to package and have
[I CC: this to the mailing list since I think this is of public intrest.
Hope you don't mind]
On Thu, 12 Jun 1997, Brian S. Julin wrote:
> On Thu, 12 Jun 1997, Christian Schwarz wrote:
> > What is your problem exactly? We could easily change our standard to
> > "cpan-xxx.deb", for example.
>
>
Christian Schwarz <[EMAIL PROTECTED]> writes:
[snip]
> I just had a look at an (old) index file of CPAN. The ".tar.gz" of the
> modules have better names for us, for example: "Date-GetDate-2.00.tar.gz".
> This could easily be converted to "lib-date-getdate-perl_2.00.deb".
Sounds good.
[snip]
>
On Mon, 9 Jun 1997, Brian S. Julin wrote:
> On Mon, 9 Jun 1997, Christian Schwarz wrote:
> > I think this naming scheme is quite reasonable. What does everyone else
> > think about it?
>
> What do you do if you do have a package turn up with an underscore
> in its name?
We could easily replace
"Brian S. Julin" <[EMAIL PROTECTED]> writes:
> However I will end up with a major headache if I cannot reliably
> map perl module names to debian package names.
One solution is to simply add a new field to the control file. dpkg &
friends do preserve extra fields. `Perl-Module:' perhaps?
Guy
On Mon, 9 Jun 1997, Christian Schwarz wrote:
> I think this naming scheme is quite reasonable. What does everyone else
> think about it?
What do you do if you do have a package turn up with an underscore
in its name?
> (I'm definitely against having more special characters in file names, as
> `+
[I'm pulling this thread over to debian-devel since I think this might be
intresting for more people.]
On Sun, 8 Jun 1997, Brian S. Julin wrote:
> Yeah, fine, close the report. Should I open one with the
> deb-make maintainer about it's permissiveness, or will
> you? Maybe I'll take it up late
Raul Miller writes in email to me:
> I presume you're familiar with the gnu conventions for labelling
> target/host architectures? [e.g. i486-unknown-linux]
>
> If not, I'd like to draw your attention to them.
Yes, I am, thanks.
Do people think the architecture names as handled by dpkg should
(Moved to debian-devel)
Raul Miller writes ("Re: FTP Installation & Package Naming Conventions"):
> If you lose track of the architecture on an executable, you can use
> 'file' to figure things out. I suppose it would be nice to have some
> similar mechanism for
brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> >brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> >> Also, while the versions are not choosen by Debian, the format in which
> >> they are
, but this is probably not necessary.
I agree, and in any case this would be a lot more work, because I
don't currently scan the msdos tree.
brian white writes ("Re: FTP Installation & Package Naming Conventions "):
> How about another field in "Packages-Master"
95 matches
Mail list logo
