[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

upstream and packaging monotone branches


Many packages in the ada-france monotone repository rely on two
- $(upstream_branch) contains at least a tag for each upstream version
- $(debian_branch) tracks changes in the ./debian/ subdirectory

Working on the package starts with something like
$ mtn -r t:foo-X.Y checkout $(dir)
$ rm -rf $(dir)/_MTN
$ mtn -r h:$(debian_branch) checkout $(dir)

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
- mentioning bar makes mtn ignore the ./bar file, but also all changes
  to ./debian/bar. These changes are silently ignored during commits.
- escaping special characters is not natural (dot for example)

Why not merge $(upstream_branch) changes into $(debian_branch) each
time an upstream version is released?

The merge cannot fail in normal circumstances, since all Debian stuff
is located in the specific ./debian subdirectory.

Working only starts with
$ mtn -r h:$(debian_branch) checkout dir

Jumping from a package version to another is easy with "mtn update
-t$(debian_tag)" even if there has been an upstream release in

No ".mtn-ignore" file is needed anymore. It becomes a good thing that
mtn reports every (most probably unwanted) change outside ./debian.

The mtn database size is only marginally increased for packages
allready tracking upstream tarballs content.

The only cost I can see is an added complexity in patches handling.
- They should be unapplied before committing
- A recent dpkg unapplies all patches it has applied during the build,
  except in case of build failure. This means that a failed build will
  need a manual "quilt pop -a".
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.


Reply to: