Page MenuHomeFreeBSD

Bump sysutils/backuppc to 3.3.0_1
ClosedPublic

Authored by milki on Jun 7 2014, 6:38 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 23 2024, 11:43 AM
Unknown Object (File)
Dec 19 2023, 11:47 PM
Unknown Object (File)
Nov 11 2023, 11:07 PM
Unknown Object (File)
Nov 7 2023, 2:45 AM
Unknown Object (File)
Nov 6 2023, 11:45 PM
Unknown Object (File)
Nov 6 2023, 5:32 PM
Unknown Object (File)
Oct 10 2023, 10:06 PM
Unknown Object (File)
Oct 6 2023, 1:43 AM
Subscribers
None

Details

Reviewers
swills
eadler
Summary

Bump sysutils/backuppc to 3.3.0_1

  • Support StageDir
  • Add CONFLICTS (prepare to new port sysutils/backuppc-devel)
  • Add LICENSE
  • BackupPC.pod: add =encoding declaration (fix build with perl5.18)
  • Add DOCS options

PR: 189799
Submitted by: Alexander Moisseev <moiseev@mezonplus.ru> (maintainer)

Test Plan

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

milki retitled this revision from to Bump sysutils/backuppc to 3.3.0_1.
milki updated this object.
milki edited the test plan for this revision. (Show Details)
milki added reviewers: swills, eadler.

I think the logic for the config file may be missing an "!", but it might be better to just use "@sample" if you can.

sysutils/backuppc/Makefile
98

Doesn't this overwrite a users config file?

In D189#3, @swills wrote:

I think the logic for the config file may be missing an "!", but it might be better to just use "@sample" if you can.

So I followed up with the developer here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189799

This is the intended upgrade process for backuppc. The config file needs to be modified during the process and thus, it is included in the plist and overwritten during the install/deinstall process.

In D189#4, @milki wrote:

So I followed up with the developer here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189799

This is the intended upgrade process for backuppc. The config file needs to be modified during the process and thus, it is included in the plist and overwritten during the install/deinstall process.

Strange. So the config file isn't specific to the user? If so, then fine, overwrite it. But if the config file is specific to the user, then we shouldn't overwrite it, we should leave it and give a pkg-message to update it.

Also, I think that with staging the logic to install the config file in the Makefile isn't needed because the @exec stuff from plist gets run at install time.

In D189#5, @swills wrote:

Strange. So the config file isn't specific to the user? If so, then fine, overwrite it. But if the config file is specific to the user, then we shouldn't overwrite it, we should leave it and give a pkg-message to update it.

I'll ask again. I think this is fine if its the normal backuppc upgrade procedure and that it understands local configurations. My suspicion is that it essentially fixes syntax for the next version and adds new defaults.

Also, I think that with staging the logic to install the config file in the Makefile isn't needed because the @exec stuff from plist gets run at install time.

That makes sense. If the local file has been modified since install, will it be properly overwritten by the port on upgrade/reinstall or would it be considered a dirty file and left untouched.

sysutils/backuppc/Makefile
90–92

I'd prefer a patch rather than sed here, but up to you.

96

is this for WWW files? Does %%WWWDIR%% not work?

97

Why is this not %%DATADIR%%? Do users often want to tweak it? d

129–133

I think we can use ${MKDIR} instead here?

In D189#6, @milki wrote:

I'll ask again. I think this is fine if its the normal backuppc upgrade procedure and that it understands local configurations. My suspicion is that it essentially fixes syntax for the next version and adds new defaults.

So it's not really a config file?

That makes sense. If the local file has been modified since install, will it be properly overwritten by the port on upgrade/reinstall or would it be considered a dirty file and left untouched.

If the file has been modified, it won't be overwritten.

In D189#8, @swills wrote:
In D189#6, @milki wrote:

That makes sense. If the local file has been modified since install, will it be properly overwritten by the port on upgrade/reinstall or would it be considered a dirty file and left untouched.

If the file has been modified, it won't be overwritten.

This would cause issues because the maintainer intends for the file to be overwritten by the port.

I tested this with my on devel/gitolite port. I deleted content from a file that was listed in pkg-plist after installing the port; and on deinstall/install, re-install (upgrade), it seems to restore the file properly. This would contradict your statement -.-

In D189#9, @milki wrote:

This would cause issues because the maintainer intends for the file to be overwritten by the port.

Ok, then perhaps we shouldn't have any of the logic and just treat it as a normal file. Seems odd, but I trust you and the maintainer on it.

I tested this with my on devel/gitolite port. I deleted content from a file that was listed in pkg-plist after installing the port; and on deinstall/install, re-install (upgrade), it seems to restore the file properly. This would contradict your statement -.-

Hmm, was this using @sample? Perhaps I'm confused.

In D189#10, @swills wrote:

I tested this with my on devel/gitolite port. I deleted content from a file that was listed in pkg-plist after installing the port; and on deinstall/install, re-install (upgrade), it seems to restore the file properly. This would contradict your statement -.-

Hmm, was this using @sample? Perhaps I'm confused.

Ah. I did not do this with an @sample file, but rather a normal file listed in the plist.

In D189#5, @swills wrote:

Also, I think that with staging the logic to install the config file in the Makefile isn't needed because the @exec stuff from plist gets run at install time.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189799#c8

The maintainer makes a point here. The backuppc user doesn't exist until install which happens after stage. How would chown work in a port for new users then?

The maintainer makes a point here. The backuppc user doesn't exist until install which happens after stage. How would chown work in a port for new users then?

Sorry it took me so long to reply to this.

I think you should be able to do the chown in the plist, such as the way the puppet port does it:

@exec /usr/sbin/chown -Rh puppet:puppet /var/puppet

If that doesn't work, we'll find a way.

In D189#8, @swills wrote:
In D189#6, @milki wrote:

I'll ask again. I think this is fine if its the normal backuppc upgrade procedure and that it understands local configurations. My suspicion is that it essentially fixes syntax for the next version and adds new defaults.

So it's not really a config file?

That makes sense. If the local file has been modified since install, will it be properly overwritten by the port on upgrade/reinstall or would it be considered a dirty file and left untouched.

If the file has been modified, it won't be overwritten.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189799#c15

The maintainer has done his best to test things and really doesn't want to use @sample unless its absolutely necessary.

sysutils/backuppc/Makefile
96

The currently defined CGIDIR is in ${PREFIX}/www/cgi-bin. ${WWWDIR} would be in ${PREFIX}/www/${PORTNAME}, The location would change.

These ports define a similar CGIDIR:

http://svnweb.freebsd.org/ports/head/mail/mailgraph/Makefile?revision=356948&view=markup#l21
http://svnweb.freebsd.org/ports/head/www/MT/Makefile?revision=338047&view=markup#l38
http://svnweb.freebsd.org/ports/head/sysutils/monitorix/Makefile?revision=337166&view=markup#l31

The backuppc wiki seems to suggest using ${WWWDIR} though.
http://sourceforge.net/apps/mediawiki/backuppc/index.php?title=Mini_httpd#download_and_install_backuppc

So if the maintainer wants it in www/cgi-bin instead of www/backuppc/cgi-bin, it seems like defining CGIDIR like this seems to be appropriate.

swills edited edge metadata.

I think this is OK now as all the issues have been explained. That is, the config files aren't really config files, so overwriting them is OK. And the CGIDIR is fine too. Similarly, the other issues are purely cosmetic. Approved.

This revision is now accepted and ready to land.Jun 23 2014, 5:31 PM
milki edited edge metadata.

Maintainer submitted a new patch with some of our suggestions.

Minor updates for DOCS and lint

milki requested a review of this revision.Jul 5 2014, 8:05 PM
milki edited edge metadata.

I hesitate to mention it, but we're trying to avoid muting install commands, so all the @ under do-install probably should be removed. Go ahead and do that (don't bother asking submitter) and submit a new rev and I think that should take care of it.

milki edited edge metadata.

Unsilence do-install steps

In D189#23, @swills wrote:

I hesitate to mention it, but we're trying to avoid muting install commands, so all the @ under do-install probably should be removed. Go ahead and do that (don't bother asking submitter) and submit a new rev and I think that should take care of it.

That's good to know. I have a port that mutes steps as well because I thought it was fine. It makes sense not to mute though, even if its noisy.

swills edited edge metadata.

Some people dislike @stopdaemon, some don't. Personally, I'd remove it, but it's not wrong at the moment. Also, the config files that end in .sample would get the exact same thing and be shorter/more readable if you used @sample, see http://www.freebsd.org/doc/en/books/porters-handbook/plist-config.html but they're not wrong as is either. Likewise the directories could be @dirrmtry but aren't wrong. So, since we've been around and around on this port so much and everything here is functional, I'm going to approve it. Make the changes I've suggested if you want, but commit it either way.

This revision is now accepted and ready to land.Jul 7 2014, 11:51 AM