Richard Levitte <[email protected]> writes: > Ludovic Brenta <[email protected]> said: > ludovic> No package "holds the database" currently; monotone-server > ludovic> creates /var/lib/monotone/default.mtn but does not own this > ludovic> file (anything under /var/lib belongs to the sysadmin, not > ludovic> the packages). > > I'm not talking about ownership, just about the fact that > monotone-server has the power to create the database (upon first > installation) and to destroy it (done upon purge, of course).
The fact that monotone-server creates the database is not a problem. The fact that it can destroy the database is a problem. We must consider two scenarii: * aptitude purge monotone-server Here the sysadmin presumably wants to delete the database; we must do that only after the sysamin confirms, of course. I believe this is the current state of the package (though I've never purged a monotone-server package before, so I don't know for sure). * aptitude install monotone-usher Here the sysadmin presumably wants not only to retain the database but also publish it with usher. If the database was previously published with monotone-server, we must instruct the sysadmin to remove monotone-server but not the database before the migration to monotone-usher can take place. Additionally, installing monotone-usher should discover all databases in /var/lib/monotone (that are owned by the monotone special user) and offer to publish them. This is only nice to have, not a hard requirement. > ludovic> If you want usher to act as a proxy to a > /var/lib/monotone/default.mtn > ludovic> created by monotone-server, I suggest a migration step in the > postinst > ludovic> script of monotone-usher. > > Yeah, but then I'm thinking about the possibility that the admin has > extended /etc/monotone/hooks.lua, or that xe wants to switch back to > monotone-server, and I can easily see things get tangled up there if > we're not veeeeery careful. After all, I'd believe most people will > regard their changes, as well as the database, as gold. That kind of > carefulness is made much easier by having the data being handled by a > separate package. Switching back to monotone-server is another scenario entirely. A complete switch-back would involve merging all databases that are published by usher into a single database published by monotone-server. I'm not sure many people would want that. So, It is OK with me if you don't support it in the first upload; this can be added later on, or never. > ludovic> I do not rely on the "UNRELEASED" part in the changelog (that was > first > ludovic> introduced by Fancis, IIRC) but if you think this is nice, we can > turn it > ludovic> into a policy. > > I see it as a marker that this has not been released to Debian yet, > that we're still working things out, that kind of thing. This is how > I've interpreted it so far... but maybe it's meant to mark that it > hasn't been released upstream? I really don't know, all I really have > is the following from the manual page for debchange: I agree with your interpretation; UNRELEASED is therefore redundant with tags. The absence of a tag is equivalent to UNRELEASED; the presence of a tag means this revision has been uploaded. So, feel freee to use UNRELEASED in addition to tags but I personally don't pay attention to UNRELEASED. -- Ludovic Brenta. _______________________________________________ Monotone-debian mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-debian
