[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-debian] Usher and monotone-server
|
From: |
Richard Levitte |
|
Subject: |
Re: [Monotone-debian] Usher and monotone-server |
|
Date: |
Thu, 25 Nov 2010 15:09:57 +0100 (CET) |
In message <address@hidden> on Thu, 25 Nov 2010 14:26:10 +0100, Ludovic Brenta
<address@hidden> said:
ludovic> Richard Levitte wrote:
ludovic>
ludovic> > Hey, I'm having a look at the debian packages for monotone and usher,
ludovic> > and I've started thinking that there's a need to split up
ludovic> > monotone-server into two packages, one that holds the database and
one
ludovic> > that's just the server startup (new names could be monotone-common
and
ludovic> > monotone-server-monotone). The goal is to have usher being able to
ludovic> > handle the older structure along with all other projects, so both
ludovic> > monotone-server-monotone and (for example) monotone-server-usher
would
ludovic> > depend on monotone-common while conflicting with each other.
ludovic>
ludovic> No package "holds the database" currently; monotone-server creates
ludovic> /var/lib/monotone/default.mtn but does not own this file (anything
under
ludovic> /var/lib belongs to the sysadmin, not 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).
ludovic> I would think that monotone-usher should work the same way.
ludovic> I do not think there is a need for a "common" package; seen
ludovic> another way, the common package is monotone. It is not a
ludovic> problem for me if monotone-usher conflicts with
ludovic> monotone-server; in fact I think this is appropriate since
ludovic> usher will(?) listen on the default port number of
ludovic> monotone-server.
So you're telling me that as long as I have them conflict with each
other, it should be safe?
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.
ludovic> > Also, what is our policy on tagging the revisions on
ludovic> > org.debian.monotone? Is that only to be done when things have been
ludovic> > accepted, or is it to be done when we think we have something
working?
ludovic> > If it's the latter, I'm thinking we could tag
debian-monotone-0.99.1-1
ludovic> > (after making the last change in changelog, of course, as it's
ludovic> > currently marked UNRELEASED ;-)), unless there are other things that
ludovic> > need to be cleared.
ludovic>
ludovic> My policy is to tag only what I upload to Debian. For monotone, the
ludovic> naming scheme for the tags is
ludovic> monotone-debian-${upstream_version}-${upload_number}. Also, I attach a
ludovic> "reviewed-by" cert on specific revisions that I review. This means that
ludovic> I've reviewed this revision and all its ancestors. An uploaded
revision is
ludovic> implicitly reviewed, so a tag counts as a "reviewed-by" cert.
Makes perfect sense.
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:
--release, -r
Finalize the changelog for a release. Update the changelog
timestamp. If the distribution is set to UNRELEASED, change it
to the distribution from the previous changelog entry (or
another distribution as specified by --distribution). If there
are no previous changelog entries and an explicit distribution
has not been specified, unstable will be used.
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
"
L
6S-jF %
\Fw
2 ({
(address@hidden<<+$)/,!"
#'
I KW/J9Nff###$# +N , +F
+!0
LN ,YFx+1jY~UkT
'&
h1=\
0U8 H
*
q H
*
qH-?I
M
La;
Pczt>>S
\)"B
\)"B
\)"B
\)"BF e(&2 .0
Q:
#&
/
+=
&
gcct_h~
[Qd>l~z[co Iw!oM^HXXz 5)Tj :$:
2 $ 3 { $ 3 {-#q=5 [\$
jYSv9v9[[[[3
#
9& #
2
g% 2ZWwVM
e{I77\)"Bg8f;
#
&%#$jBSvM
H0oNo
bDD
Rhn::\
~2 J$ Pi"Q
0 !
54
)
. !
54
)
<6<%PYWWf6fffffffffff
Y f+fH
M?HL7LL$L
!4D$<h N99 `hYp%1 >address@hidden@B444\v
"" "I+ B:F
:%",%& : .&* 5
Wp46 2P>address@hidden)address@hidden
&I&+ 27
P<%$F= 'I:wr 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.