Re: upstream and packaging monotone branches
I forgot to tell where the idea comes from: http://vcs-pkg.org.
http://wiki.debian.org/PackagingWithGit describes a concrete
implementation, if not perfect.
> I have everything needed to do this in the upstream Makefiles (for the
> packages I maintain, anyway). You could add something similar in the
> Debian makefile if you don't maintain the upstream one.
> So work starts with 'make <nice target'.
I also put these commands into a Make target. As the snippet
(re)creates the whole package and directory tree from the monotone
database, I prefer to store the snippet outside foo/Makefile and
foo/debian/rules.
My point was that foo/debian/ is conceptually a patch to foo/. It is
shipped as such in a source package, after all.
> > Often, the maintainer lists $(upstream_branch) files into
> > "./.mtn-ignore" in the $(debian_branch), so that their names do not
> > pollute "mtn list missing && mtn list unknown && mtn status" output.
> > This is cumbersome, and error-prone:
> > - each upstream release may add files and requires manual updating
> This hasn't been a problem for me.
Putting all file names outside debian into .mtn-ignore is a repetitive
task that should be, if possible, avoided, or else done by a program.
.mtn-ignore is a work-around for specific situations that monotone
cannot handle. With the workflow I am proposing, monotone could handle
all files.
> > - mentioning bar makes mtn ignore the ./bar file, but also all changes
> > to ./debian/bar.
> no, .mtn-ignore can be made directory-specific.
Ok, this can be done with ^bar$. I missed that in the documentation.
> > - escaping special characters is not natural (dot for example)
> Nothing about computers is "natural"!
You are right.
> > 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.
> > 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 guess that you allready use second option to compare Debian package
versions based on the same upstream.
Ideally, comparing trees is monotone's job, and two physical versions
of the same file should be avoided.
There is also a disk storage size gain.
> > No ".mtn-ignore" file is needed anymore. It becomes a good thing that
> > mtn reports every (most probably unwanted) change outside ./debian.
> This is good, although one of the deb helpers does the same thing.
> to be precise, add debian/source/local-options, with the lines:
> unapply-patches
> abort-on-upstream-changes
> this file is used by dpkg-source.
These options are not needed anymore. Dpkg-source fails by default
instead of generating a patch when it detects changes outside
./debian/, and unapplies the patches it has to applied.
> 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.
> > 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.
> > 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.
Reply to: