In message <[email protected]> on Thu, 25 Nov 2010 18:41:57 +0100, Ludovic Brenta <[email protected]> said:
ludovic> Richard Levitte <[email protected]> writes: ludovic> > Ludovic Brenta <[email protected]> said: ludovic> > ludovic> No package "holds the database" currently; monotone-server ludovic> > ludovic> creates /var/lib/monotone/default.mtn but does not own this ludovic> > ludovic> file (anything under /var/lib belongs to the sysadmin, not ludovic> > ludovic> the packages). ludovic> > ludovic> > I'm not talking about ownership, just about the fact that ludovic> > monotone-server has the power to create the database (upon first ludovic> > installation) and to destroy it (done upon purge, of course). ludovic> ludovic> The fact that monotone-server creates the database is not a problem. ludovic> The fact that it can destroy the database is a problem. We must ludovic> consider two scenarii: ludovic> ludovic> * aptitude purge monotone-server ludovic> ludovic> Here the sysadmin presumably wants to delete the database; we must do ludovic> that only after the sysamin confirms, of course. I believe this is the ludovic> current state of the package (though I've never purged a monotone-server ludovic> package before, so I don't know for sure). ludovic> ludovic> * aptitude install monotone-usher ludovic> ludovic> Here the sysadmin presumably wants not only to retain the database but ludovic> also publish it with usher. If the database was previously published ludovic> with monotone-server, we must instruct the sysadmin to remove ludovic> monotone-server but not the database before the migration to ludovic> monotone-usher can take place. OK, points so far. ludovic> Additionally, installing monotone-usher should discover all databases in ludovic> /var/lib/monotone (that are owned by the monotone special user) and ludovic> offer to publish them. This is only nice to have, not a hard ludovic> requirement. I strongly disagree with "not a hard requirement". The database isn't alone, there's usually a set of keys, a read-permissions / write-permissions pair of files, and possibly a corresponding hooks.lua or somesuch to boot. There's no way to know where they are, what location they are in or whatever stroke the admin's fancy. In that case, I think I would rather go with automagically adding a catch-all usher server for the default stuff if they are in place, and tell the admin that if there are others, he should probably use a specific incantation of usherctl (a script I've committed to usher recently) to add them. ludovic> > ludovic> If you want usher to act as a proxy to a /var/lib/monotone/default.mtn ludovic> > ludovic> created by monotone-server, I suggest a migration step in the postinst ludovic> > ludovic> script of monotone-usher. ludovic> > ludovic> > Yeah, but then I'm thinking about the possibility that the admin has ludovic> > extended /etc/monotone/hooks.lua, or that xe wants to switch back to ludovic> > monotone-server, and I can easily see things get tangled up there if ludovic> > we're not veeeeery careful. After all, I'd believe most people will ludovic> > regard their changes, as well as the database, as gold. That kind of ludovic> > carefulness is made much easier by having the data being handled by a ludovic> > separate package. ludovic> ludovic> Switching back to monotone-server is another scenario entirely. A ludovic> complete switch-back would involve merging all databases that are ludovic> published by usher into a single database published by monotone-server. ludovic> I'm not sure many people would want that. So, It is OK with me if you ludovic> don't support it in the first upload; this can be added later on, or ludovic> never. Good points, ok, I'll quit worrying about that one. ludovic> > ludovic> I do not rely on the "UNRELEASED" part in the changelog (that was first ludovic> > ludovic> introduced by Fancis, IIRC) but if you think this is nice, we can turn it ludovic> > ludovic> into a policy. ludovic> > ludovic> > I see it as a marker that this has not been released to Debian yet, ludovic> > that we're still working things out, that kind of thing. This is how ludovic> > I've interpreted it so far... but maybe it's meant to mark that it ludovic> > hasn't been released upstream? I really don't know, all I really have ludovic> > is the following from the manual page for debchange: ludovic> ludovic> I agree with your interpretation; UNRELEASED is therefore redundant with ludovic> tags. The absence of a tag is equivalent to UNRELEASED; the presence of ludovic> a tag means this revision has been uploaded. So, feel freee to use ludovic> UNRELEASED in addition to tags but I personally don't pay attention to ludovic> UNRELEASED. hmm, ok Cheers, Richard -- Richard Levitte [email protected] http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish _______________________________________________ Monotone-debian mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-debian
