Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I have a folder ~/Packaging where all my public and private packages are in. For example, in the Packaging/think-rotate folder, there is the typical Debian stuff, like so:

think-rotate-2.5.2/
think-rotate-2.5.2.orig/
think-rotate-2.6/
think-rotate-2.6.orig/
think-rotate_1.0.tar.gz
think-rotate_2.5.2-0ubuntu1.debian.tar.gz
think-rotate_2.5.2-0ubuntu1.dsc
think-rotate_2.5.2-0ubuntu1_source.build
think-rotate_2.5.2-0ubuntu1_source.changes
think-rotate_2.5.2.orig.tar.gz@
think-rotate_2.5.2.tar.gz
think-rotate_2.5.orig.tar.gz@
think-rotate_2.5.tar.gz
think-rotate_2.6-0ubuntu1_all.deb
think-rotate_2.6-0ubuntu1_amd64.build
think-rotate_2.6-0ubuntu1_amd64.changes
think-rotate_2.6-0ubuntu1.debian.tar.gz
think-rotate_2.6-0ubuntu1.dsc
think-rotate_2.6-0ubuntu1_source.build
think-rotate_2.6-0ubuntu1_source.changes
think-rotate_2.6-0ubuntu1_source.stable.upload
think-rotate_2.6.orig.tar.gz@
think-rotate_2.6.tar.gz

I have some script that goes through my projects and generates the latest .tar.gz from my source code. So for the matter of this question, new tar archieves pop up in the packaging directory every now and then.

Since I do not want to run uupdate ../….tar.gz on every project by hand, I wrote a Python 3 script which takes care of that, runs debuild -S and dput to upload it to my Launchpad PPA, and then debuild to build it for my local machine.

The Debian changelog is just populated with the default “New upstream release” message. Those packages are more for organized local deployment, than for the general public.

The script then also uses apt-cache show to check whether the latest version is installed, and if not, uses dpkg -i to install that package.

This works somewhat, but I encountered a couple problems with my current version of that script:

  • When I upgrade my machine to a new Ubuntu version, it does not rebuild everything. So I have a lot of packages that did not receive any upstream updates, and the latest version in my PPA is quantal, not raring.

  • Packages are build for amd64 on my main computer, and often cannot be installed on my other computer, which has i686. Some packages are all, so that does not hurt. But I would need to rebuild the any packages on that machine. The Launchpad PPA takes care of building it for every architecture, but my script did not upload that package for raring, see first problem.

To summarize, the workflow has to contain all those steps:

  • Extract new source tar archive and update the debian/changelog. (uupdate)

  • If not already uploaded to PPA, build a source package and upload it to the Launchpad PPA. But only do this, if this is public package, do not upload my private packages to the PPA. (debuild -S and dput)

  • If the package needs to be upgraded locally, build a binary package for the current architecture and install it. (debuild and debi or dpgk -i)

  • Check if the series is outdated, i. e. the latest upload was for quantal, and the current system runs on raring. If so, rebuild the source again and upload to PPA.

Before you say that I should work on every package by hand, keep in mind that I have 43 packages sitting around, and I would really like to save work here.

I could work on my script to work around the current problems, but I'd rather use something that already works instead of rolling my own. Is there some tookchain or workflow that maintainers use in order to keep so many packages up to date in their PPAs or official repositories?


Update 2013-07-08: I now worked on the script to handle the problems as well. But I am still interested in a canonical solution.

share|improve this question
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.