Re: osmpbf package
On Mi, Mär 12, 2014 at 03:00:47 +0100, Andreas Tille wrote:
> On Wed, Mar 12, 2014 at 02:22:00PM +0100, Jochen Topf wrote:
> >
> > 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.
>
> 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.
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.
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.
> > If we want more people to help with Debian packaging we need to keep
> > this simple.
>
> I think there is no point in having *more* people doing packaging
> outside Debian.
>
> > 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.
>
> For me it makes perfectly sense if you focus on upstream but maintaining
> a "competing" debian/ dir without beeing familiar with Debian packaging
> stuff is a way of thinking I can not follow. Why exactly do you want to
> repeat a work which is done by somebody else by at the same time
> confirming that you can not do a better job than this somebody else?
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. 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. 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.
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...
Jochen
--
Jochen Topf jochen@remote.org http://www.jochentopf.com/ +49-721-388298
Reply to: