[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: New .debs of tla utilities uploaded
From: |
Andreas Rottmann |
Subject: |
[Gnu-arch-users] Re: New .debs of tla utilities uploaded |
Date: |
Fri, 27 Feb 2004 17:28:25 +0100 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
John Goerzen <address@hidden> writes:
> If your upstream is using Arch already, here's what I do:
>
> 1. tla tag the upstream into package--head--1.0 in my archive (this
> is the naming convention used by tla-buildpackage). I usually
> tla cacherev the base-0 as well.
>
> 2. Check out this into a temporary area, observing the
> packagename-version convention on this dir.
>
> 3. rm -rf \{arch\} `find . -name .arch-ids`
>
> 4. Add the skeleton debian/ dir
> 5. Build the preliminary source package
> 6. tla-importdsc on the source package.
> 7. Proceed as normal.
>
> Now, tla-importdsc is smart enough to realize that the source is
> already in the archive. It will still run a tla commit over the
> upstream source, but the effect will be essentially committing a null
> changeset. It will then tag it over to the debian branch, and commit
> the debian/ changes like usual.
>
> For new upstream versions, one would merge it into the head branch like
> usual, then create a config for it in configs/upstream/packagename.
> tla-buildpackage requires a config be present for each upstream version
> number you use (so it can build the orig.tar.gz on demand). Then of
> course, you'd merge it over to the debian side like usual too.
>
Thanks for your explanation. I decided to go a different route,
however: I just keep the debian directory in the --debian
category. Fixes to upstream go to --head, so upstream can merge back
from that (and I can merge small upstream fixes into --head). My
debian config then roots the two parts at approriate places, for
hacking pleasure.
I then started to build a script, with about the same goals as your's,
however stressing the following:
1) Designed for upstream having an archive
2) Use tla in "read-only-mode", so archive modification is left to the
user (at least as a start)
3) Handle autogenerated files in the tarballs (which are not in the
Archive, of course) gracefully. I must admit I don't know how well
your scripts handle this.
The idea for 3) is the following:
a) Create a patch script (similar to those used by dpatch),
corresponding to the changes from upstream release tarball (as in
Arch, i.e. package--head--patch-X) to the target version (as
specified in the config, i.e package--head--patch-X+N).
b) Untar orig.tar.gz
c) "tla get" the desired debian directory into it
b) put the patch script under debian/++head.patches
c) hook executing "debian/++head.patches -patch|-unpatch"
into the build process (I'll write CDBS rules for that)
You may now cry out: what a waste of effort! My stuff has most/all of
that functionality! Well, in part you're right, but I tought that such
a "patch exporter" for Arch might be useful in general; also, since I
built the exporter on ITLA[0], the exporter itself is just ~50 lines.
Regards, Andy
--
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Say NO to Software Patents! -- http://petition.eurolinux.org/