Re: upstream and packaging monotone branches
Nicolas Boulenguez <nicolas.boulenguez@free.fr> writes:
> My point was that foo/debian/ is conceptually a patch to foo/. It is
> shipped as such in a source package, after all.
As long as foo/debian is not part of upstream, we have to tolerate
workarounds. As long as all tasks are fairly well automated, it's not
much of a problem.
> Putting all file names outside debian into .mtn-ignore is a repetitive
Why "repetitive"? I only do it once per package.
I guess also when upstream adds new directories; that doesn't happen
often.
> task that should be, if possible, avoided, or else done by a program.
It might be nice to have an inverse logic in .mtn-ignore, that says
"ignore all except the following: debian".
> .mtn-ignore is a work-around for specific situations that monotone
> cannot handle. With the workflow I am proposing, monotone could handle
> all files.
I agree that mtn prefers to handle all files in a directory tree; that
is what good cm systems do :).
I think the better way to make that happen here is to make 'debian' the
root directory for the mtn branch containing 'debian'. I think I
suggested that back when I got started with Debian, but it wasn't what
people were used to, so I adopted the common style.
dpkg handles all files outside of 'debian'; mtn handles all files inside
'debian'. Nice clean division.
>> > Why not merge $(upstream_branch) changes into $(debian_branch) each
>> > time an upstream version is released?
>> That is more cumbersome, in my opinion.
>
> As you argued before, repetitive tasks can be done with a
> nice Make target. For example, the git-import-orig script
> - extracts the upstream tarball
> - commits its changes to the upstream branch
> - merges with the debian branch (there can be not conflict)
> among other things like downloading the tarball with uscan.
That's a good point; I had not realized there could not be a conflict.
>> > Jumping from a package version to another is easy with "mtn update
>> > -t$(debian_tag)" even if there has been an upstream release in
>> > between.
>> I always check out new major versions in new workspaces, so I can
>> compare new to old more easily.
>
> Could you explain why
> "cd .. && diff -rN foo-1 foo-2 --exclude=debian/ --exclude=_MTN/"
> is easyier than
> "mtn diff -r t:foo-1-3 -r t:foo-2-7"?
I never do either of those; I ediff (Emacs front-end to diff) specific
files, looking for the reason for a specific problem.
You can do that with mtn commands (DVC provides some support), but it's
much easier to have a full checkout of each. Then the normal Emacs
workspace browsing commands work, for example (including those that rely
on compiler output). Disk space is _very_ cheap!
>> It would be nice if mtn handled nested workspaces; that would
>> accomplish this goal nicely.
>
> If I understand well, you would like monotone to handle a physical
> directory with files belonging to two branches. A Debian version
> allways relies on a specific upstream release. Updating to a Debian
> revision should ideally automatically update the upstream files to the
> depended upstream revision.
That's a good point; the two revisions are related.
My main problem with your proposal is the duplication of CM control; you
now have copies of the upstream files in two CM systems. In general,
copies are anathema to CM. It requires user discipline to ensure they
don't diverge.
making mtn control only 'debian' is a cleaner fix.
>> > The only cost I can see is an added complexity in patches handling.
>> > - They should be unapplied before committing
>> This is extremely problematic!
>
> You might as well store the patched ustream tree in the Debian branch.
> Both solutions have pros and contras. That's the reason why
> dpkg-source decided to unapply the patches only if it has applied
> them during the build.
Right. I think dpkg now does a good job of managing the files outside of
debian, so we should let it.
>> > I guess that everyone does something like "debuild clean && mtn list
>> > missing && mtn list unknow && mtn status" before "mtn commit", so that
>> > should not be a problem.
>
>> DVC is better than these command line operations.
>
> Thanks for the reference, I will take a look at that.
It's in ada-france mtn: org.emacs.dvc. That's more up-to-date for mtn
than the DVC bzr server (although I do sync them occasionally).
--
-- Stephe
Reply to: