[Gnu-arch-users] Re: New .debs of tla utilities uploaded

[Andreas Rottmann]

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/