[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: debian package status
From: |
Erik Sandberg |
Subject: |
Re: debian package status |
Date: |
Mon, 31 May 2004 23:55:18 +0200 |
User-agent: |
KMail/1.6.2 |
On Friday 28 May 2004 12.35, Pedro Kroger wrote:
> * Mats Bengtsson (address@hidden) wrote:
> > I don't know about the package naming conventions in Debian, but
> > wouldn't it be better to use a name like lilypond (without version
> > number) for the stable versions and lilypond-unstable (or whatever)
> > for the unstable versions. Otherwise, you will in principle need a new
> > "Replaces" statement for each new major revision of LilyPond.
>
> that's true. Debian handles cases like this in 2 different ways. One
> is the "snapshot" package, (like in mozilla-snapshot) that is what you
> described (except that the snapshot usually refer to cvs
> snapshots). The other way is appending versioning numbers like I did.
>
> Initially I was inclined to name it "lilypond-snapshot" or
> "lilypond-unstable" like you suggested, but I realized that it would
> be good to be able to have different major versions installed at the
> same time. For instance: suppose you typeseted a complex piece with
> lily 2.0 in the past and need a pdf right away. Now you use lilypond
> 2.2. Suppose that convert-ly did its job but still remains a few (or a
> lot) of things to be corrected and re-tweaked. Of course the right
> thing to do is to convert to newer versions, but if you are short of
> time and just want to print, wouldn't be good if you had previous
> version installed?
>
> That's the way debian handles python, for example. Debian has packages
> for python1.5, python2, python2.1, python2.2, and so on.
>
> Of course the drawback of this approach is that the user has to
> specifically uninstall older versions, if he/she wishes.
I have 2 suggestions here (which are more food for thought than opinions):
1. How about adding two metapackages 'lilypond-stable' and
'lilypond-unstable' (or whatever the names would be), depending on the latest
lilypondX.Y package? This would elimintate the drawback.
2. How about using Mats' naming convention for all odd-numbered versions of
lilypond? It's not normal to want any other odd-numbered lilypond packages
than the very latest unstable one.
Erik