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. _______________________________________________ Monotone-debian mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-debian
