Package naming dilemma

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Package naming dilemma

Dave Korn

      Heya all,

  I want to ITP remake (the make debugger) and I can't figure out how to name
it.

  The upstream source is called remake-3.80+dbg-0.61.tar.gz.  If I plug this
into g-b-s unaltered, it decides the parts of the package name are:

DKAdmin@ubik /usr/build/package/remake> ./remake-3.80+dbg-0.61-1.sh
PKG remake-3.80+dbg VER 0.61 REL 1
BASEPKG remake-3.80+dbg-0.61
SHORTPKG remake-3.80+dbg-0.61
FULLPKG remake-3.80+dbg-0.61-1

  The problem with this approach is that if I wanted to patch it up to
make-3.81 at some point, it would look like a different package, instead of a
newer version of the same one.  It's an unusual situation; effectively
upstream are referring to it as a combination of two packages, each with a
full release number.  I could bodge all the release numbers together like
this:

DKAdmin@ubik /usr/build/package/remake> ./remake+dbg-3.80.0.61-1.sh
PKG remake+dbg VER 3.80.0.61 REL 1
BASEPKG remake+dbg-3.80.0.61
SHORTPKG remake+dbg-3.80.0.61
FULLPKG remake+dbg-3.80.0.61-1

- is it OK to have a VER with four parts?  Anyone got a better idea?

  Incidentally, it's also part of my plan to maintain it with the old cygwin
make DOS path-handling patches, which I hope will satisfy a lot of the current
complaints on the main list.  :D

    cheers,
      DaveK
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Reini Urban
Dave Korn schrieb:

>   I want to ITP remake (the make debugger) and I can't figure out how to name
> it.
>
>   The upstream source is called remake-3.80+dbg-0.61.tar.gz.  If I plug this
> into g-b-s unaltered, it decides the parts of the package name are:
>
> DKAdmin@ubik /usr/build/package/remake> ./remake-3.80+dbg-0.61-1.sh
> PKG remake-3.80+dbg VER 0.61 REL 1
> BASEPKG remake-3.80+dbg-0.61
> SHORTPKG remake-3.80+dbg-0.61
> FULLPKG remake-3.80+dbg-0.61-1
>
>   The problem with this approach is that if I wanted to patch it up to
> make-3.81 at some point, it would look like a different package, instead of a
> newer version of the same one.  It's an unusual situation; effectively
> upstream are referring to it as a combination of two packages, each with a
> full release number.  I could bodge all the release numbers together like
> this:
>
> DKAdmin@ubik /usr/build/package/remake> ./remake+dbg-3.80.0.61-1.sh
> PKG remake+dbg VER 3.80.0.61 REL 1
> BASEPKG remake+dbg-3.80.0.61
> SHORTPKG remake+dbg-3.80.0.61
> FULLPKG remake+dbg-3.80.0.61-1
>
> - is it OK to have a VER with four parts?  Anyone got a better idea?
I already have this package my private setup.ini as makedb for some
years. I also ITP'd it Nov 2004 because I found it useful from time to time.

makedb-3.80+dbg_0.2

Add http://xarch.tu-graz.ac.at/publ/cygwin/ to your mirror path and
search for makedb in Devel
remake is really a stupid name.

--
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

makedb, based on remake-3.80+dbg-0.2 (i686-pc-cygwin)
----------------------------------
The make debugger as extra package side-by-side to existing make.

Runtime requirements: (versions given or later)
  cygwin-1.5.11-1
  make-3.80-1
 
Build requirements: (versions given or later)
  cygwin-1.5.11-1
  zlib-1.2.1-1
  libtool-devel-1.5.10 (if GCC >= 3.3.3)
  gcc-3.3.3-3
  binutils-20040725-2
  make-3.80
  ash-20031007
  fileutils-4.1-2
  sed-4.1.2-1

Canonical homepage:
  http://bashdb.sourceforge.net

Canonical download:
  http://prdownloads.sourceforge.net/bashdb/

-------------------------------------------------------------------------------

Build instructions:
  unpack remake-3.80+dbg_0.2-<CYGREL>.tar.bz2
    if you use setup to install this src package, it will be
         unpacked under /usr/src automatically
  cd /usr/src
  ./remake-3.80+dbg_0.2-<CYGREL>.sh all

This will create:
  /usr/src/remake-3.80+dbg_0.2-<CYGREL>.tar.bz2
  /usr/src/remake-3.80+dbg_0.2-<CYGREL>-src.tar.bz2

Or use './remake-3.80+dbg_0.2-<CYGREL>.sh prep' to get a patched source directory.

-------------------------------------------------------------------------------

Files included in this package:

  /usr/bin/makedb.exe
  /usr/share/doc/Cygwin/makedb-3.80+dbg_0.2-1.README
  /usr/share/doc/makedb-3.80+dbg_0.2/ABOUT-NLS
  /usr/share/doc/makedb-3.80+dbg_0.2/AUTHORS
  /usr/share/doc/makedb-3.80+dbg_0.2/ChangeLog
  /usr/share/doc/makedb-3.80+dbg_0.2/COPYING
  /usr/share/doc/makedb-3.80+dbg_0.2/INSTALL
  /usr/share/doc/makedb-3.80+dbg_0.2/NEWS
  /usr/share/doc/makedb-3.80+dbg_0.2/README
  /usr/share/doc/makedb-3.80+dbg_0.2/README.customs
  /usr/share/doc/makedb-3.80+dbg_0.2/README.makedb
  /usr/share/doc/makedb-3.80+dbg_0.2/README.W32
  /usr/share/doc/makedb-3.80+dbg_0.2/TODO
  /usr/share/emacs/site-lisp/makedb.el
  /usr/share/info/makedb.info-1.gz
  /usr/share/info/makedb.info-2.gz
  /usr/share/info/makedb.info.gz
  /usr/share/locale/da/LC_MESSAGES/makedb.mo
  /usr/share/locale/de/LC_MESSAGES/makedb.mo
  /usr/share/locale/es/LC_MESSAGES/makedb.mo
  /usr/share/locale/fr/LC_MESSAGES/makedb.mo
  /usr/share/locale/gl/LC_MESSAGES/makedb.mo
  /usr/share/locale/he/LC_MESSAGES/makedb.mo
  /usr/share/locale/hr/LC_MESSAGES/makedb.mo
  /usr/share/locale/ja/LC_MESSAGES/makedb.mo
  /usr/share/locale/ko/LC_MESSAGES/makedb.mo
  /usr/share/locale/nl/LC_MESSAGES/makedb.mo
  /usr/share/locale/pl/LC_MESSAGES/makedb.mo
  /usr/share/locale/pt_BR/LC_MESSAGES/makedb.mo
  /usr/share/locale/ru/LC_MESSAGES/makedb.mo
  /usr/share/locale/sv/LC_MESSAGES/makedb.mo
  /usr/share/locale/tr/LC_MESSAGES/makedb.mo
  /usr/share/locale/zh_CN/LC_MESSAGES/makedb.mo

-------------------------------------------------------------------------------

Port Notes:

----- version makedb-3.80+dbg_0.2-1 -----

First cygwin package, based on remake-3.80+dbg-0.2, similar to bashdb.
Rename to makedb.
Doesn't overwrite any files from the "make" package.

Cygwin port maintained by: Reini Urban <[hidden email]>
Please report problems, suggestions, etc. dependent on their
nature to one of the following:

    Rocky Bernstein <rocky [at] panix [dot] com>  (upstream maintainer)
    cygwin @ cygwin.com (cygwin issues)
 
sdesc: "make debugger"
category: Devel
requires: cygwin make
Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Christopher Faylor-2
In reply to this post by Dave Korn
On Sat, Aug 12, 2006 at 08:47:04PM +0100, Dave Korn wrote:
>Incidentally, it's also part of my plan to maintain it with the old
>cygwin make DOS path-handling patches, which I hope will satisfy a lot
>of the current complaints on the main list.  :D

I'm not too wild about having two different makes with two different
capabilities in the distribution.

cgf
Reply | Threaded
Open this post in threaded view
|

RE: Package naming dilemma

Dave Korn
On 14 August 2006 14:17, Christopher Faylor wrote:

> On Sat, Aug 12, 2006 at 08:47:04PM +0100, Dave Korn wrote:
>> Incidentally, it's also part of my plan to maintain it with the old
>> cygwin make DOS path-handling patches, which I hope will satisfy a lot
>> of the current complaints on the main list.  :D
>
> I'm not too wild about having two different makes with two different
> capabilities in the distribution.
>
> cgf


  <shrugs>  I was proposing to take all those dos-path-handling gripes off
your shoulders.  If that seems like too much trouble, I don't need to.  remake
can install alongside standard make without any conflicts.  I don't see why
this should be inherently any more confusing than having both make and scons
in the distro; they're two separate packages with differing names and similar
functionality.

  Put it another way: what kind of confusion or other problem could you see
arising?  Perhaps I can think of a way to mitigate it.

    cheers,
      DaveK
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Christopher Faylor-2
On Mon, Aug 14, 2006 at 03:57:12PM +0100, Dave Korn wrote:

>On 14 August 2006 14:17, Christopher Faylor wrote:
>>On Sat, Aug 12, 2006 at 08:47:04PM +0100, Dave Korn wrote:
>>>Incidentally, it's also part of my plan to maintain it with the old
>>>cygwin make DOS path-handling patches, which I hope will satisfy a lot
>>>of the current complaints on the main list.  :D
>>
>>I'm not too wild about having two different makes with two different
>>capabilities in the distribution.
>>
>
><shrugs> I was proposing to take all those dos-path-handling gripes off
>your shoulders.

It won't take them off my shoulders.  It will just require more
explanation.

>Put it another way: what kind of confusion or other problem could you
>see arising?  Perhaps I can think of a way to mitigate it.

  "My makefile doesn't work!"

  "You're using MS-DOS filenames.  Use remake instead."

  "What's remake?  Why do I have to do this?  Why can't I use GNU make?  It
  seems to me..."

As opposed to:

  "My makefile doesn't work!"

  "You're using MS-DOS filenames.  Fix your makefile."

The point is that we want people to get out of the habit of using MS-DOS
filenames under cygwin whereever possible.  It was actually a bug that
allowed the previous version of make to use MS-DOS paths without
specifying the --win32 option on the command line.

>I don't see why this should be inherently any more confusing than
>having both make and scons in the distro; they're two separate packages
>with differing names and similar functionality.

I believe that I had objections when bashdb was first proposed because
there were two packages with one code base and two different
maintainers.  While we have that now for vim, and maybe a small number
of other packages, I don't think it is a good idea to promulgate this
kind of arrangement.

cgf

Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Christopher Faylor-2
On Mon, Aug 14, 2006 at 11:18:28AM -0400, Christopher Faylor wrote:
>[snip]

I just wanted to say that I really love the idea of something like
remake.  I have spent way too much of my life debugging makefiles and
have wished for something like remake for a long time.

So, I am not averse to the idea of getting remake into the distribution,
somehow, if someone can come up with a creative way to do this
(/etc/alternatives maybe?).  I just don't like overloading remake by
adding a "feature" which has nothing to do with its intended purpose.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Reini Urban
Christopher Faylor schrieb:

> On Mon, Aug 14, 2006 at 11:18:28AM -0400, Christopher Faylor wrote:
>> [snip]
>
> I just wanted to say that I really love the idea of something like
> remake.  I have spent way too much of my life debugging makefiles and
> have wished for something like remake for a long time.
>
> So, I am not averse to the idea of getting remake into the distribution,
> somehow, if someone can come up with a creative way to do this
> (/etc/alternatives maybe?).  I just don't like overloading remake by
> adding a "feature" which has nothing to do with its intended purpose.

What for?

I have /usr/bin/makedb.exe
and I checked that no files from any other package is overwritten by my
makedb package.
I attached the README with the filelist in my first mail.
--
Reini
Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Christopher Faylor-2
On Thu, Aug 17, 2006 at 09:00:22PM +0200, Reini Urban wrote:

>Christopher Faylor schrieb:
>>On Mon, Aug 14, 2006 at 11:18:28AM -0400, Christopher Faylor wrote:
>>>[snip]
>>
>>I just wanted to say that I really love the idea of something like
>>remake.  I have spent way too much of my life debugging makefiles and
>>have wished for something like remake for a long time.
>>
>>So, I am not averse to the idea of getting remake into the distribution,
>>somehow, if someone can come up with a creative way to do this
>>(/etc/alternatives maybe?).  I just don't like overloading remake by
>>adding a "feature" which has nothing to do with its intended purpose.
>
>What for?

What five?

>I have /usr/bin/makedb.exe and I checked that no files from any other
>package is overwritten by my makedb package.  I attached the README
>with the filelist in my first mail.

remake is more than just a make debugger and I think it deserves to
be used and advertised in that way.

cgf
Reply | Threaded
Open this post in threaded view
|

RE: Package naming dilemma

Dave Korn
On 17 August 2006 20:04, Christopher Faylor wrote:

> On Thu, Aug 17, 2006 at 09:00:22PM +0200, Reini Urban wrote:
>> Christopher Faylor schrieb:
>>> On Mon, Aug 14, 2006 at 11:18:28AM -0400, Christopher Faylor wrote:
>>>> [snip]
>>>
>>> I just wanted to say that I really love the idea of something like
>>> remake.  I have spent way too much of my life debugging makefiles and
>>> have wished for something like remake for a long time.
>>>
>>> So, I am not averse to the idea of getting remake into the distribution,
>>> somehow, if someone can come up with a creative way to do this
>>> (/etc/alternatives maybe?).  I just don't like overloading remake by
>>> adding a "feature" which has nothing to do with its intended purpose.
>>
>> What for?
>
> What five?

  I was assuming that the "extra feature" was my proposal to merge in the dos
path-handling patch.

>> I have /usr/bin/makedb.exe and I checked that no files from any other
>> package is overwritten by my makedb package.  I attached the README
>> with the filelist in my first mail.
>
> remake is more than just a make debugger and I think it deserves to
> be used and advertised in that way.

  It is?

  I mean, I knew it was also a dessert polish, and even a floor topping, but
what *else* is it?

  Certainly the remake homepage doesn't mention anything else that seems
comparable in scale to the debugging features.


    cheers,
      DaveK
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Max O Bowsher
In reply to this post by Reini Urban
Reini Urban wrote:
> I have /usr/bin/makedb.exe

Is this 'makedb' name in any way official?

Personally, I am opposed to renaming 'remake' to 'makedb' (in both the
executable and package name) as a Cygwin-local change, if that's what it is.

Max.


signature.asc (195 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Christopher Faylor-2
In reply to this post by Dave Korn
On Thu, Aug 17, 2006 at 08:32:33PM +0100, Dave Korn wrote:

>On 17 August 2006 20:04, Christopher Faylor wrote:
>
>> On Thu, Aug 17, 2006 at 09:00:22PM +0200, Reini Urban wrote:
>>> Christopher Faylor schrieb:
>>>> On Mon, Aug 14, 2006 at 11:18:28AM -0400, Christopher Faylor wrote:
>>>>> [snip]
>>>>
>>>> I just wanted to say that I really love the idea of something like
>>>> remake.  I have spent way too much of my life debugging makefiles and
>>>> have wished for something like remake for a long time.
>>>>
>>>> So, I am not averse to the idea of getting remake into the distribution,
>>>> somehow, if someone can come up with a creative way to do this
>>>> (/etc/alternatives maybe?).  I just don't like overloading remake by
>>>> adding a "feature" which has nothing to do with its intended purpose.
>>>
>>> What for?
>>
>> What five?
>
>  I was assuming that the "extra feature" was my proposal to merge in the dos
>path-handling patch.

You were assuming correctly.

>>> I have /usr/bin/makedb.exe and I checked that no files from any other
>>> package is overwritten by my makedb package.  I attached the README
>>> with the filelist in my first mail.
>>
>> remake is more than just a make debugger and I think it deserves to
>> be used and advertised in that way.
>
>  It is?
>
>  I mean, I knew it was also a dessert polish, and even a floor topping, but
>what *else* is it?
>
>  Certainly the remake homepage doesn't mention anything else that seems
>comparable in scale to the debugging features.

I guess this is a YMMV situation.  It seems to me that this is intended as
a replacement for GNU make.

    remake is a patched and modernized version of GNU make utility that
    adds improved error reporting, the ability to trace execution in a
    comprehensible way, and a debugger.  The debugger lets you set
    breakpoints on targets, show and set variables in expanded or
    unexpanded form, inspect target descriptions, see the target call
    stack, and even execute arbitrary GNU make fragments (e.g.  add a
    dependency to an existing target).

cgf
Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Reini Urban
In reply to this post by Max O Bowsher
Max Bowsher schrieb:
> Reini Urban wrote:
>> I have /usr/bin/makedb.exe
>
> Is this 'makedb' name in any way official?

Nope. It's private only.

> Personally, I am opposed to renaming 'remake' to 'makedb' (in both the
> executable and package name) as a Cygwin-local change, if that's what it
> is.

--
Reini
Reply | Threaded
Open this post in threaded view
|

RE: Package naming dilemma

Dave Korn
In reply to this post by Christopher Faylor-2
On 17 August 2006 21:30, Christopher Faylor wrote:

> I guess this is a YMMV situation.  It seems to me that this is intended as
> a replacement for GNU make.
>
>     remake is a patched and modernized version of GNU make utility that
>     adds improved error reporting, the ability to trace execution in a
>     comprehensible way, and a debugger.  The debugger lets you set
>     breakpoints on targets, show and set variables in expanded or
>     unexpanded form, inspect target descriptions, see the target call
>     stack, and even execute arbitrary GNU make fragments (e.g.  add a
>     dependency to an existing target).
>
> cgf


  Yes, it's basically a drop in replacement.  Well, it basically IS make.  The
extra features aren't on by default.  The only difference in normal operation
is more verbose error output - that could just conceivably throw off some
automated build systems, but other than that, it's identical.  Which is why I
thought having the two side by side, one with support for DOS paths and one
without, might make people happy.  Most people would want only one or the
other.  All the make-dos-path complainers would simply link /bin/make to
/bin/remake and be happy[*].

  BTW I would also not want to change the name from upstream.  It is *so* much
the twin/counterpart of make that the name is entirely suitable.


    cheers,
      DaveK

* -  OK, maybe expecting them to be happy with the onerous task of having to
make a link in their bin dirs is too much.
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

Re: Package naming dilemma

Christopher Faylor-2
On Fri, Aug 18, 2006 at 10:38:29AM +0100, Dave Korn wrote:

>On 17 August 2006 21:30, Christopher Faylor wrote:
>
>> I guess this is a YMMV situation.  It seems to me that this is intended as
>> a replacement for GNU make.
>>
>>     remake is a patched and modernized version of GNU make utility that
>>     adds improved error reporting, the ability to trace execution in a
>>     comprehensible way, and a debugger.  The debugger lets you set
>>     breakpoints on targets, show and set variables in expanded or
>>     unexpanded form, inspect target descriptions, see the target call
>>     stack, and even execute arbitrary GNU make fragments (e.g.  add a
>>     dependency to an existing target).
>
>  Yes, it's basically a drop in replacement.  Well, it basically IS make.  The
>extra features aren't on by default.  The only difference in normal operation
>is more verbose error output - that could just conceivably throw off some
>automated build systems, but other than that, it's identical.  Which is why I
>thought having the two side by side, one with support for DOS paths and one
>without, might make people happy.  Most people would want only one or the
>other.  All the make-dos-path complainers would simply link /bin/make to
>/bin/remake and be happy[*].
>
>  BTW I would also not want to change the name from upstream.  It is *so* much
>the twin/counterpart of make that the name is entirely suitable.

...and that's why I suggested /etc/alternatives.

cgf
Reply | Threaded
Open this post in threaded view
|

RE: Package naming dilemma

Dave Korn
On 18 August 2006 15:20, Christopher Faylor wrote:

> On Fri, Aug 18, 2006 at 10:38:29AM +0100, Dave Korn wrote:

>>  BTW I would also not want to change the name from upstream.  It is *so*
>> much the twin/counterpart of make that the name is entirely suitable.
>
> ...and that's why I suggested /etc/alternatives.
>
> cgf


  Agreed; nothing I have said was meant to discount that option.  I'll take a
look at how the alternatives mechanism works.

  Heh, I didn't need to go to all the trouble of figuring out how to get it to
name the info files 'remake' instead of 'make' after all!

  Must remember to send upstream the build-outside-srcdir patch though.

    cheers,
      DaveK
--
Can't think of a witty .sigline today....