[Pkg-giraffe-discuss] Z-push packaging

Mon May 22 05:57:36 UTC 2017

On Mon, May 22, 2017 at 07:50:41AM +0200, Carsten Schoenert wrote:
> 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 transitional packages might also be useful if z-push will be
available via stretch-backports at one point.
Cheers,
 -- Guido

> 
> 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
> 
> _______________________________________________
> Pkg-giraffe-discuss mailing list
> Pkg-giraffe-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-giraffe-discuss
>