[Pkg-crosswire-devel] updating bibletime

[Jonathan Marsden]

On 03/19/2011 08:59 AM, Daniel Glassey wrote:

> I might have missed it but I think it would be very helpful to
> document what you do somewhere - maybe a debian/README.source file
> would be appropriate?[1]

I thought README.source was for explaining any patch system the package
uses, with several standard ones being found at places like:

  /usr/share/doc/quilt/README.source and
  /usr/share/doc/dpatch/README.source.gz

So it hadn't occurred to me to put "how I update packages" in there.
I'd expected each packager to have their own preferred workflow for
doing this.  How you get there doesn't really matter, as long as the end
result (the updated package) is correct :)

What I do is probably more manual than the "official" bzr-is-wonderful
approach one is perhaps supposed to use, but it works for me, and I feel
as though I understand each step.

I just do something like:

 (0) update my bzr tree for the package, just in case.
 (1) download the new tarball (I have a download-url.txt file in each
     packaging directory, as a reminder of where to find these!)
 (2) unpack tarball at the same level as my existing bzr package tree
     (which is called main),
 (3) move all the files across from the new tree into the old one
     cd bibletime-2.8.1
     for i in `find . -type f` ; do mv ../main/$i  # or similar
     If there are new directories, mkdir them in the main tree and
     then repeat the for command above.
 (4) untar the new tarball again and diff the new tree with my packaging
     tree, ignoring everything under debian/ and everything with .bzr/
     in it.  Any differences are usually files present before, that are
     not in the new version, or which were renamed in the new version.
 (5) in main, deal with the deleted/renamed files using bzr rm or
     mv and bzr mv as needed.
 (6) bzr add * , so all the new files are now known to bzr.
 (7) recheck bzr status, diff -ur --brief the trees, make sure nothing
     was lost.  Only difference should now be the debian/ tree and .bzr/
     stuff.
 (8) Update debian/changelog
 (9) I'm in business: debcommit, then build and test new package, fix
     any new lintian complaints, etc.
 (10) bzr sign-my-commits
 (11) bzr push   # to push my work back up to LP.
 (12) bzr export ../exported  # to have a non-bzr copy
 (13) in ../exported, edit debian/changelog for each Ubuntu release I
      want to build and then   debuild -S -sa   for each one.
 (14) for i in *source.changes ; do dput developer-testing $i ; done
 (15) Wait for all the PPA builds, fix any that fail!

The above is from memory, I did not test as I wrote it down, so it might
not be 100% what I really do, but it should be very close!

I am sure there are better / more automated ways, but this has worked
for me for quite a while now.  Is it really worth documenting in
README.source?  To me, it is just "how I generally play around with
updating packages that are in bzr"!  Every packager will have their own
approach.

> If it would be a helpful improvement, I think we should set it up to
> have an upstream-xxx tag

So you want me to bzr tag the tree once the update is done, at around
step 8.5 above?  Sounds reasonable and easy, just not something I have
done, or really seen a need for.  If this is a new standard, someone
should perhaps update the Packaging Guide to include it.

> Having said that, I would say that if it isn't broken, and changing
> things isn't a useful improvement, then it doesn't need 'fixed'.

That's been my approach -- I think Dima is quite into the latest bzr
stuff, which is fine, and probably makes him more efficient doing some
of this work.  I have stayed more "traditional" because I first learned
all this packaging stuff without LP bzr integration, and so for me, the
new bzr integration sometimes is more confusing than helpful.  Either I
"do it wrong", or I feel that I am not in control, and not really
understanding what each step does, which is a feeling I don't like!

Hoping this helps, even if Dima and some others may be highly amused at
the way I do things :)  If you really think I should add the above info
as debian/README.updating-this-package  or something, say so :)

Jonathan