Re: [Monotone-debian] Usher and monotone-server

[Richard Levitte]

In message <address@hidden> on Thu, 25 Nov 2010 18:41:57 +0100, Ludovic Brenta 
<address@hidden> said:

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> >
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                         address@hidden
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish