Differential D189
Bump sysutils/backuppc to 3.3.0_1 Authored by milki on Jun 7 2014, 6:38 PM. Tags None Referenced Files
Subscribers None
Details Bump sysutils/backuppc to 3.3.0_1
PR: 189799
Diff Detail
Event TimelineComment Actions I think the logic for the config file may be missing an "!", but it might be better to just use "@sample" if you can.
Comment Actions 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. Comment Actions 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. Comment Actions 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.
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. Comment Actions So it's not really a config file?
If the file has been modified, it won't be overwritten. Comment Actions 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 -.- Comment Actions 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.
Hmm, was this using @sample? Perhaps I'm confused. Comment Actions Ah. I did not do this with an @sample file, but rather a normal file listed in the plist. Comment Actions 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? Comment Actions
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. Comment Actions 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.
Comment Actions 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. Comment Actions 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. Comment Actions 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. Comment Actions 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. | ||||||||||||||||||||||||||||||||||||||||