lilypond-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]