[Privoxy-devel] Privoxy packaging for Debian

Fabian Keil fk at fabiankeil.de
Wed Jan 20 17:31:31 UTC 2021


Roland Rosenfeld <roland at spinnaker.de> wrote on 2021-01-19:

> On Mo, 18 Jan 2021, Fabian Keil wrote:
> 
> > Thanks a lot for the detailed description.
> > I've added some tags and committed it.
> 
> Great.  I just did some cleanup (removed the old cruft, added a
> subsection for the snapshot build, fixed indent of the commands).
> Hope it's okay, that I pushed it to the repository (usually I try to
> reduce my changes to the debian directory).

It's fine, thanks.

> > On the other hand if the debian files will not match the Privoxy
> > version advertised in the dist tarball name they may cause
> > confusion.
> > 
> > Something to think about some more ...
> 
> Maybe we should modify the version number for packages that are hosted
> at sf.net/privoxy.org in a way, that clearly shows, that this is not
> an official Debian package.
> 
> So while the debian.org package is versioned 3.0.30-1, we could use
> 3.0.30-1~pp-1 for the proivoxy.org version referring p.p hostname.
> "~" is lower than everything else in Debian version numbering, so
> 3.0.30-1 from debian.org overwrites 3.0.30-1~pp-1, which should be
> intended, since an official debian.org release is expected to be more
> stable and is automatically updated on security issues.
> 
> Then we can use 3.0.30~git-snapshot-1 for all snapshot builds, where
> 3.0.30~git is lower than 3.0.30-1~pp-1. So a release always overwrites
> the snapshot with the same version number.  Next snapshot after
> release of 3.0.30-1~pp-1 will be 3.0.31~git-snapshot-1.
> 
> I should soon change the version number in debian/changelog in
> preparation of the 3.0.30 release to 3.0.30-1~pp-1.
> 
> Hmmm, but this version number change of the pp releases minimally
> modifies my release workflow, where I currently use the debian.org
> version numbers, but I'll defer changing the documentation until I
> once implemented the new workflow with 3.0.30. 

The proposed version scheme makes sense to me as well.

> > The GNUMakefile currently filters the file using
> > slackware/rc.privoxy as destination file name so renaming the source
> > file to the same name would probably result in an empty file.
> 
> I wasn't aware of this.  Wouldn't it be a better idea to rename it to
> rc.privoxy.in like other files that were rebuild using ./configure?

I have no strong feelings about this so I've changed it
to rc.privoxy.in like you suggested.

> BTW: What do you think about moving the provoxy man page from man
> section 1 to 8, since this is a daemon?  At least man(1) on Linux
> systems tells me, that this would be the correct section:
> 
>        The table below shows the section numbers of the manual
>        followed by the types of pages they contain.
> 
>        1   Executable programs or shell commands
>       [...]
>        8   System administration commands (usually only for root)
> 
> So on Debian systems usually every daemon is installed to /sbin or
> /usr/sbin and the man page is installed into man8.
> 
> If you like this idea,
> https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob;f=debian/patches/15_mansection8.patch
> contains the referring patch, which I use in Debian for 18 years now.

I have no strong feelings about this either.

If testing doesn't show any problems I'll apply your patch tomorrow.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.privoxy.org/pipermail/privoxy-devel/attachments/20210120/9d876da3/attachment.bin>


More information about the Privoxy-devel mailing list