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

Updating a package; ediquette and procedure questions



Hi, again. I'm the guy who builds RPMs trying to understand the Debian
way. Still.

In Ubuntu Hardy, the version of ggobi is not the most recent release.
It is about 1 year out of date.  Since I've been supplying RPM for
ggobi for a couple of years, i thought it would be instructive to see
if I could take the newer source code package and apply the existing
Debian diff and dsc files to make a package.

The new package from the ggobi team is:  ggobi-2.1.7.tar.bz2

The Debian packaging process still seems awkward to me, but I think
I'm starting to make it work. Here's how I went about it.

1. Get sources for ggobi-2.1.6 from Ubuntu site

$ apt-get source ggobi

I want that because I need to see how the previous package was built.
I need to find out if there are patched under the debian directory
that need to  be eliminated or adjusted.

2. Change name of new package, open it up

$ cp ggobi-2.1.7.tar.bz2 ggobi_2.1.7.orig.tar.bz2
$ tar xjvf ggobi_2.1.7.orig.tar.bz2

3. Go into the new source tree, manually copy over the debian
directory from the previous version:

$ cd ggobi-2.1.7
$ cp -R ../ggobi-2.1.6/debian .

4. Edit the debian/changelog to set the version number and put in my
name so the gpg key signing process will succeed.

I had not realized the package builder was detecting the version of
the deb package from the changelog.  Surprise!

5. Build the package

 $ debuild -r fakeroot

That ends with a lot of warnings about the source code not being
found, because it is looking for ggobi_2.1.7.orig.tar.gz, but i have
the bz2 file instead.

In the end, I could find no way to make that go away except for
re-packaging the source code from a bz2 file to gz.  After that I'm
able to build both the deb package and the source pieces.

Here are my questions, in no particular order.

1. Is this roughly how you would go about building a package for a new
source tarball?

2. In Ubuntu, or Debian more generally, what happens when package
maintainers don't stay up to date?  It is a little tough to figure out
who is responsible for a package sometimes, there is an
OriginalMaintainer and other names in the changelog.  If you email the
person you think is in charge, and don't get an answer, what do you
do?

This reminds me, I noticed today that in Ubuntu, the supplied version
of R is 2.6.2, but I need 2.7, the current version.  Same problem as
with ggobi, except I really need the Ubuntu team to update theirs,
because there are subsidiary programs like ggobi that are going to
look for the new R, as opposed to old R.  And some R components cannot
be built with the old version of R, such as the current  package
"cairoDevice".

3. What do you do with code distributed in bz2 files? I searched
pretty hard for some guidance from Mr. Google, got none, except for
people agreeing that debian packaging should have a way to deal with
bzip files more seamlessly.  The bz2 compression is much better, the
filesize is 2.5 megabytes, compared against 3.4 meg.

4. Suppose I succeed in building some packages and want to post them
on a website.  In RPM world, there was a simple program "createrepo"
that would crawl over a directory structure and do all the work needed
to index files and make them available to programs like "yum".  In
Ubuntu, I'm looking for a similarly "easy" approach to creating a
repository, but most of the tipsheets I find are designed for people
who want to build a mirror repository of all distribution packages.
Can you throw me a pointer?

PJ

-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas


Reply to: