Re: [Monotone-debian] Usher and monotone-server (was: Moving on...)

[Ludovic Brenta]

Richard Levitte wrote:

> Hey, I'm having a look at the debian packages for monotone and usher,

> and I've started thinking that there's a need to split up

> monotone-server into two packages, one that holds the database and one

> that's just the server startup (new names could be monotone-common and

> monotone-server-monotone).  The goal is to have usher being able to

> handle the older structure along with all other projects, so both

> monotone-server-monotone and (for example) monotone-server-usher would

> depend on monotone-common while conflicting with each other.



No package "holds the database" currently; monotone-server creates

/var/lib/monotone/default.mtn but does not own this file (anything under

/var/lib belongs to the sysadmin, not the packages).



I would think that monotone-usher should work the same way.  I do not

think there is a need for a "common" package; seen another way, the common

package is monotone.  It is not a problem for me if monotone-usher

conflicts with monotone-server; in fact I think this is appropriate since

usher will(?) listen on the default port number of monotone-server.



If you want usher to act as a proxy to a /var/lib/monotone/default.mtn

created by monotone-server, I suggest a migration step in the postinst

script of monotone-usher.



> So....  what I'm thinking of doing with now is to start a branch where

> I start experimenting with this, say org.debian.monotone.new-server or

> something like that.

> 

> I was going to ask you how one splits up a package in two others, but

> it looks like 7.6 in

> http://www.debian.org/doc/debian-policy/ch-relationships.html

> has some (enough?) information on this...



Feel free to ask specific questions if anything is unclear.



> Anyway, please tell me what you think of this.

> 

> Also, what is our policy on tagging the revisions on

> org.debian.monotone?  Is that only to be done when things have been

> accepted, or is it to be done when we think we have something working?

> If it's the latter, I'm thinking we could tag debian-monotone-0.99.1-1

> (after making the last change in changelog, of course, as it's

> currently marked UNRELEASED ;-)), unless there are other things that

> need to be cleared.



My policy is to tag only what I upload to Debian.  For monotone, the

naming scheme for the tags is

monotone-debian-${upstream_version}-${upload_number}.  Also, I attach a

"reviewed-by" cert on specific revisions that I review. This means that

I've reviewed this revision and all its ancestors.  An uploaded revision is

implicitly reviewed, so a tag counts as a "reviewed-by" cert.



I do not rely on the "UNRELEASED" part in the changelog (that was first

introduced by Fancis, IIRC) but if you think this is nice, we can turn it

into a policy.



-- 

Ludovic Brenta.