[Pkg-giraffe-discuss] Z-push packaging

[Carsten Schoenert]

Hello Roel,

Am 11.05.2017 um 12:30 schrieb Roel van Meer:
> Hi everyone,
> 
> I have more or less finished everything I wanted to do with the packaging of  
> Z-push.  Apart from some open questions (see below) it would be nice if  
> someone could have a look at the current state of affairs, and let me know  
> if anything can be improved or should be changed.

first thanks for your effort on this package! And sorry for a delayed
answer. I have to less time currently to also contribute to this package
that I'm in the end not using at all.

> I've been rebasing a lot since my previous reports here, so if you cloned  
> the repo before, you might need to make a new clone.
> 
> Current code can be found here:
>   https://github.com/roelvanmeer/z-push-packaging
>   https://travis-ci.org/roelvanmeer/z-push-packaging

That's not a problem at least for me, the package hasn't re-entered the
Debian archives. So it's on one side a good possibility for you to get
in touch with the packaging of Debian packages.

> First some questions I still have, that one of you might be able to answer:
> 
> - The control file still mentions d-push in some of the fields (Vcs-Git, Vcs- 
> Browser).  Should these be changed to z-push in anticipation of a new repo  
> that is to be created on anonscm.d.o, or must that be done later?

You can adjust these fields to z-push to make clear the current state I
think. But I would use the existing repository to work on the z-push
source package. We can make a symlink on Alioth to combine d-push with
z-push.

> - The same goes for the .po files: these mention d-push at packages.debian.org.  
> What should I do with those?

I'm not sure if the debconf stuff is still needed here, if it's useful
then it shouldn't be dropped.

> - We currently build many d-push subpackages for oldlibs.  But as far as I  
> can see, none of the packages these are meant to replace were ever released  
> (I cannot find them on packages.debian.org, in any case).  So I am wondering  
> whether it is really necessary to have these?  Carsten, you started these,  
> could you perhaps share the reasons you had for adding them?

The transitional d-push packages would have been needed if the z-push
packages would have been make it into Stretch to provide a upgrade path
for user of the old d-push packages. But this was not happen, I'm for
simply dropping all old d-push things.

The repositories in Debian holding only old d-push* source and binary
packages until the current stable release Jessie. This will be soon
old-stable.
If you don't wanna provide backports for this release there is no need
to carry on d-push* binary packages. So I would drop them all and only
rely on z-push* packages. That's also true for the conflicts/replaces
relations to the old d-push packages. That makes the maintainers life
much easier.

> - Currently lintian complains about the build being a NMU.  Do I need to do  
> something to fix that? 

This is due your name and email isn't found in the control file, you can
add yours into the Uploaders field.

> - Upstream uses /var/lib/z-push as state dir, while the d-push package used  
> /var/lib/d-push/state.  So currently this build uses /var/lib/z-push/state.   
> Although that seems to be the better choice, it would make it quite  
> difficult to change from upstream packages to Debian packages.  Any advice?   
> Should we keep it as /v/l/z-push/state or use /v/l/z-push?

The former is the more logical place for me, but in the end it depends
on the needed content in /var/lib/z-push. If only some state saving
files are placed here directly it's o.k. to live with the upstream
choice. If there are more files stored and a subdirectory is really
useful then upstream needs to be convinced to a layout with the extra
folder.
If it's to difficult and not worth to spend energy here stay with the
upstream solution for less maintenance here.

> The current repo contains files for debian/sid and debian/jessie. The builds  
> from the last branch are used by us in production with the kopano packages  
> provided by Kopano, so that at least gives us some testing ground. Testing  
> on sid hasn't been done yet.
> 
> There are some small things I still have to do, like updating the NEWS file  
> and re-enabling provisioning, but a round of reviews would be very welcome.

As written earlier, I wouldn't have started with Jessie but if the
current state of packaging for Jessie is working well on your side there
should be only small things to adjust for unstable.
Once the freeze is over we need to update the kopanocore packages as well.

I can't promising any date to review your work more in deep, but for on
this years DebConf will be time to work finally on it and make a upload
I think.

-- 
Regards
Carsten Schoenert