[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-debian] Usher and monotone-server
Re: [Monotone-debian] Usher and monotone-server
Thu, 25 Nov 2010 21:55:08 +0100 (CET)
In message <address@hidden> on Thu, 25 Nov 2010 18:41:57 +0100, Ludovic Brenta
ludovic> Richard Levitte <address@hidden> writes:
ludovic> > Ludovic Brenta <address@hidden> 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> > 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> 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> * aptitude purge monotone-server
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
ludovic> package before, so I don't know for sure).
ludovic> * aptitude install monotone-usher
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
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
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
ludovic> > ludovic> created by monotone-server, I suggest a migration step in
ludovic> > ludovic> script of monotone-usher.
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> 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
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> > 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
ludovic> > is the following from the manual page for debchange:
ludovic> I agree with your interpretation; UNRELEASED is therefore redundant
ludovic> tags. The absence of a tag is equivalent to UNRELEASED; the presence
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
Richard Levitte address@hidden
"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish