[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#246153: RFA: unison -- file-synchronization tool for Unix and Windows



Hello,

On Sun, May 02, 2004 at 09:10:15AM +0200, Stefano Zacchiroli wrote:
> On Sun, May 02, 2004 at 05:17:12AM +0100, Robert McQueen wrote:
> > direction of synchronisation with woody boxes. Accordingly we will need
> > three source packages:
> > * unison, which builds two transition binary packages "unison", which
> > * unison-2.9.1, which builds two binary packages "unison-2.9.1", which
> > * unison-2.9.20, which is the same except with the appropriate version,
> 
> I suggest not to use version number neither in source package names nor
> in binary package ones. It would delay archive entering due to the need
> of manual processing and this would happen each time we will need to
> upload a new unison version. Why don't simply use some symbolic names?
> "unison" is fine for the transition package, for the other two dunno,
> maybe unison-devel or unison-latest and unison-stable.
> 
> > Unison has a command-line option to specify a versioned binary to use on
> > the remote end of the connection, so I believe this packaging and naming
> > scheme will allow concurrent installation of all necessary versions of
> > unison to, eg, synchronise between a sid machine with 2.9.1-gtk and a
> 
> Why not simply using the debian alternative system with a symbolic name
> of unison and the usual versioned binary names (e.g. unison-2.9.1,
> unison-2.9.20)? I think is more standard and users can tune which
> default version they want to use.
> 

I second your proposition...

We must also think that we will produce, only one version release of
package ( ie only producing unison-2.9.1, unison-2.9.20... regarding the
package unison ). So we will need to manually remove any package
unison-XXX. 

Using unison-stable, unison-latest is to my mind the best approach.

Kind regard
Sylvain Le Gall



Reply to: