Re: osmpbf package
On 03/12/2014 02:22 PM, Jochen Topf wrote:
> On Wed, Mar 12, 2014 at 12:57:40AM +0100, Sebastiaan Couwenberg wrote:
>> On 03/11/2014 11:45 AM, Jochen Topf wrote:
>>> I went through the osmpbf package and I think I have things more or less
>>> ready for a new release. I am co-maintainer of the upstream package so
>>> I have made all the changes there [1]:
>> In your recent changes you updated the Maintainer to Debian GIS, it's
>> was better when you used your own email address like in v1.3.1. The
>> Debian GIS team doesn't maintain the debian/ directory in the upstream
>> source, we only maintain the official Debian package.
>
> That was an attempt to bring the upstream debian directory as much as possible
> in line with the official debian directory. But I have changed it back to my
> email address now.
Thanks for the Maintainer change.
Can you also change the Vcs-* URLs to use the upstream git repository?
The control file then properly reflects its upstream origin.
> I don't want to live without the debian directory in the upstream repository,
> because it is so much easier to work with it than with the complex Debian
> setup. If we want more people to help with Debian packaging we need to keep
> this simple. I understand that it makes things more complex for Debian
> packagers, but would think that it could be solved on the Debian side. There
> are so many specialized build script already, somebody could come up with
> a way to solve this with a few more scripts. :-)
I understand the desire to have a debian directory in the upstream
source. It's quite convenient to easily build debian packages from the
latest upstream source to deploy on OSM infrastructure running Ubuntu
LTS for instance.
I've maintained unofficial Debian packages in my personal APT repo for
quite some time before finally taking the effort to properly contribute
the packaging to Debian. The barrier of entry to the Debian archive is
much higher than your own repo or PPA.
QGIS also maintains their own packaging in their upstream source, and
the packaging for 2.0.1 diverged quite a bit when it finally entered the
Debian unstable. Luckily QGIS upstream is also very collaborative, so
the divergence for 2.2.0 is much smaller.
Since they also host their own APT repository, this complicates the
duplicate packaging effort some what. But it's another clear example of
the need for debian packages of the latest upstream releases, that
official Debian packages cannot provide.
>> I recommend to set the Maintainer in the upstream source to you as
>> before, and in the Debian package have Debian GIS as Maintainer and you
>> as one of the Uploaders. Unless you see your role more as upstream and
>> would prefer others in the Debian GIS team to be the Uploaders. Team
>> uploads are always possible.
>>
>> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-team-upload
>
> For the time being I see myself focusing more on upstream. This might change
> in the future as I get more familiar with the Debian packaging stuff.
If you run Debian on your systems it seems an obvious choice to also
become a co-maintainer of packages your upstream of. As an OSM person I
assume you run Ubuntu LTS on your systems like the official OSM
infrastructure and a fare share of UbuntuGIS PPA users, in that case
uploading your upstream packages to the ubuntugis-unstable PPA like QGIS
does is an option to get packages of the latest upstream release into
the hands of its users.
I would like the Debian GIS Project to be the collaboration space in
which Debian, its upstreams, and its derivatives work together sharing
the workload of maintaining debian packages for their users.
With most upstream projects and most Debian GIS and OSM packages using
git this greatly eases sharing changes. I don't think the
git-buildpackage based workflow is the Answer to the Ultimate Question
of Users, Distributions, and Free Software Development. It's a step we
need to migrate from tarball based workflows. Cherry picking changes
from upstream branches is quite convenient, but we're not at the level
of seamless integration with upstream git repositories yet.
>>> * The rules file from the Debian package used dh_auto_build etc. but in
>>> upstream there are now cmake files in addition to the Makefiles, and
>>> the auto build picks up the cmake stuff. I have changed this to use
>>> the make build. (The cmake stuff has been added for Windows users.)
>>
>> You can use the option -S/--buildsystem makefile to force debhelper to
>> use a specific build system instead of auto-detecting it. I've used this
>> in the debian/rules for v1.3.1.
>>
>> http://anonscm.debian.org/gitweb/?p=pkg-grass/osmpbf.git;a=blob;f=debian/rules
>
> Great! I was sure such an option exists, but couldn't find it. I have used
> your rules file now for upstream.
The common debhelper options like -S/--buildsystem are documented in the
debhelper(7) man page, but it doesn't list the supported builsystems.
These can be found by running `dh_auto_configure -l`.
>>> * I have slightly changed the description of the packages in upstream
>>> debian/control file.
>>
>> Looks good. We can merge the change when you've released the new
>> upstream version.
>
> Okay. I have removed the ${shlibs:Depends} from libosmpbf-(java|dev) because
> I get these warnings:
>
> dpkg-gencontrol: warning: Depends field of package libosmpbf-java: unknown substitution variable ${shlibs:Depends}
> dpkg-gencontrol: warning: Depends field of package libosmpbf-dev: unknown substitution variable ${shlibs:Depends}
>
> Don't know whether that was the right thing to do.
It was. Only packages which have shared library dependencies need
${shlibs:Depends}, the symbols or shlibs files are used to generate the
required (versioned) dependencies.
The Debian Policy specifies the use the ${shlibs:Depends} in section 8.6.1:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-dpkg-shlibdeps
Pure java packages don't need it, but SWIG generated libraries for
instance do.
>>> * Upstream is at version 1.3.1. The changes I made are not in that release
>>> yet, so after some of you looked it over, I want to make a 1.3.2 release
>>> and then we can do the final Debian package.
>>
>> Have a look at the changes I made to the package for v1.3.1:
>>
>> http://anonscm.debian.org/gitweb/?p=pkg-grass/osmpbf.git
>>
>> If we can minimize the diff between the debian directory maintained
>> upstream and the debian directory maintained by the Debian GIS team I'd
>> be very happy.
>
> I think I pulled everything from Debian GIS team debian dir into upstream dir
> except "changelog", "gbp.conf", the maintainer/uploaders in "control" and
> "source/format". The last is needed for debuild to work in the upstream
> repository for some reason.
Maintaining your changelog separate from Debian is option, you can also
try to merge them.
The git-buildpackage configuration is very specific to the official
Debian package, so doesn't belong in the upstream repository.
Your debuild problem with the source format is probably this:
dpkg-source: error: can't build with source format '3.0 (quilt)':
non-native package version does not contain a revision
Because the package version number used in the upstream changelog
doesn't contain a debian revision it's assumed to be native to Debian (a
package only of use in Debian).
It's probably better to use and upstream specific debian revision that
reflects its relation to the official Debian package. If you use a
version number such as 1.3.2-0upstream1 it can coexist with the official
Debian package. The upstream version precedes the official Debian
package (1.3.2-1) and its packports (1.3.2-1~).
On the other hand, it's much more convenient to never include patches in
the upstream debian packaging, so you don't need to play tricks with
debian revisions like the above.
> I have pushed all changes to upstream and created a v1.3.2 release.
Thanks for the new release. A bit sooner than I expected even.
I've imported the v1.3.2 upstream release and made some additional minor
changes. The package is ready for unstable, but I'd rather upload
version 1.3.3-1 with some additional upstream changes (the Vcs-* URLs
mentioned above, and the below).
I don't see the need to the .gitignore in the Debian directory. The
clean target in debian/rules is intended to clean up all the artifacts
of the package build.
git-buildpackages automatically executes the clean target in
debian/rules before building the package, when only using debuild you
can run `debclean && debuild ...` to achieve the same.
It's a bit of shame to release a new upstream version only for changes
to the included debian packaging, so maybe only fix it in the upstream
git and leave it at that for now. We'll can upload the package to Debian
unstable as currently on Alioth and update to the next upstream release
when more significant changes are included.
> Jochen
Kind Regards,
Bas
--
GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: