Re: osmpbf package
Hi Jochen,
On Wed, Mar 12, 2014 at 04:04:22PM +0100, Jochen Topf wrote:
> > Without having had a look into any of this: Could you please explain
> > what exactly is easier / complex in both setups?
>
> Setup 1, only using upstream:
>
> Clone upstream repository, type "debuild -I -us -uc". Done. Any changes
> when working on upstream can immediately be tested with Debian setup.
>
> Setup 2, using the official Debian repository:
>
> You need to know about extra debian-gis repository, you need to install
> extra scripts and run them to update the repository and build everything,
> special sudo stuff needed for some kind of virtual machine setup, which
> btw. takes for ever to setup because it basically has to download a
> complete debian install. And all my changes in upstream don't show up
> there but need to be committed first, tagged with a version and through
> some way I haven't figured out yet, get imported into the official debian
> repository.
Can you please explain who this magical "you" would be? The usual way to
install is
apt-get install libosmpbf-java
at the users machine. Users should install the binary Deb package and
this currently works for binary packages resulting from 20000 source
package. If a user has reasons to not install the binary package why
should he start building from source package at all? I wonder in how
far osmpbf is different from all those other 20000 sources. If we care
for up to date packages following your upstream releases closely which
should be pretty easy thanks to your help there is no point for users to
create different than the official Debian packages. To the contrary I
as a user would regard it quite confusing.
> I see that at least some of this is necessary, some of it is maybe there
> for legacy reasons. But I only go through all of this if it is absolutely
> necessary.
So what is your purpose to create "your own" Debian packages?
> Generally when working on upstream it is no problem at all to, say add
> another doc file to be included in the package. I am working on it anyway,
> I know I have written a new doc file, and I can add it to the debian
> config. The next time, somebody creates a new official package, they will
> see the change in my debian config and pull it in. If I have to go the long
> route, it will be postponed and then forgotten. And then the debian maintainer
> will have to dig through the git log to figure out what changed and what
> changes they might have to make to the debian config.
But you can easily commit to the official packaging repository and ping
us to release a new package. I fail to see any advantage in your
suggested workflow - may be I'm too focussed on what we call "the usual
way" and might overlook something.
> Because, as we have seen, this work is *not* done by somebody else, at least
> not enough of it. If somebody had been doing this work, I wouldn't have come
> here and started to help. The Debian packages are massively lagging behind,
> some don't work at all any more.
OK, I see your point and I agree that there was some friction in the
Debian GIS team. I wonder if you might trust me that this has changed
in the last couple of monthes. There are different reasons for this.
I would recommend testifying us by just pinging here on the list for a
new upload of the status in the repository in gis.debian.org. If you
are not happy about the delay you might stick to your workflow.
> It is obvious that Debian maintainers are
> not keeping up, and I don't blame them (or maybe I have to say "us" now :-),
> there aren't just enough people to do all the work. So I think the only way
> forward is to involve upstream more, work *together* with them on packaging,
> upstream has the knowledge about their software, Debian maintainers know
> about packaging.
I fully agree that upstream involvement really helps and I really
welcome your work (specifically the Java knowledge is very welcome).
> But if that work happens in a way that a normal developer
> can't or won't participate because of the overhead I have described above,
> it will not happen.
If we *know* that you are afraid about the overhead I'd recommend you
simply push those changes you were mentioning and ping here to let
somebody check and build the package. IMHO trying this workflow is
better than maintaining competing stuff and by doing so adding extra
trouble to the final target - creating apt-get-able binary packages.
> I am not sure about how exactly all of this could best work, we'll have to
> figure this out together. But we are not living in a tar.gz-world any more. I
> have the debian repository and the upstream repository as branches in the same
> git and I can compare them and should be able to pull in changes from here to
> there and back. So having the official debian directory and the upstream one
> shouldn't be that problematic. Of course my experiences are from two packages
> only, that I have helped out with a bit, so I can't claim that this is the best
> way...
Well, osmpbf is on GitHub. So if you create a tag of your upstream
source. If you simply leave out the debian/ dir from this tag by
putting it in a separate branch as long as you do not trust us to be
quick enough this could help everybody. Finally you asked here on this
list whether we think everything in your upstream release is OK and Bas
said: Yes, except the debian/ dir and he has given reasons why this
is causing trouble.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: