Date: Sun, 03 Aug 2014 17:04:19 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 192347] [maintainer update] multimedia/universal-media-server: Update to 4.0.1 + FIXES Message-ID: <bug-192347-13-Y1fcA0mQa1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-192347-13@https.bugs.freebsd.org/bugzilla/> References: <bug-192347-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192347 --- Comment #17 from dreamcat4@gmail.com --- (In reply to John Marino from comment #14) > It still doesn't answer the question: Why mess with the pkg-plist instead= of > just fixing the script or reporting the script broken on the previous bug > report? Yeah, agree here this question is not answered by me. But I think you can't= be satisfied with my explanation, which is this: To be utterly safe in terms of FUNCTIONAL behaviour. To stay on the side of safety. Because the known test= ed FUNCTIONAL configuration (by me) is the old ways. (you say isn't correct). I still don't fully understand (myself) commiter #1's ALL of his 'pkg-plist' changes in their entirety. And this is because he didn't bother to explain = it (to me). He just said "take a look". And immediately closed / committed. My Questions, about those things I want reverted in plist (to be safer): * For a new user install: How does removal of "mkdir -p /var/entries" lead = to NO LOSS of "/var/{run,log}/universa.../" directories, needed because the 'u= ms' user isn't root, and does not have permission to write directly into '/var/log/' and '/var/run' ? Did he test that 'ums' user function correctly= / behave properly after that ? (I honestly don't know the answer to that question). * For committer#1 adding of new PLIST_SUB entry to cd / change @cwd and removing previous PLIST_SUBS for /var folders does not make more efficient = when those removed PLIST_SUB entry were still being used in rc.d script. Whether that rc.d usage was correct or not. So why make half-finished changes and expect someone else (me) to clean up your mess, and not feel jerked around = by that? * There are no other functional breakages that I am currently aware of... P= ut back "to last known previous safe configuration". Which is what the attached patch will achieve. And expends minimum time / effort for all involved to do so. That's why I said in first place "just take it". Because in the scheme = of things of the world. * Allows people involved to move on to other higher-priority issues because many other things in Ports tree are more seriously broken than this. I'm not trying to suggest that the previous changes were all wrong / unjust. But IF * I'm not knowledgable enough to fix them. And=20 * the guy who committed them made a boo-boo and didn't really do it properl= y.=20 Then I can't seriously be expected to say "just continue to do it HIS way a= nd I assume it'll all be fine," "well probably, since that was some new configuration i had never seen befo= re and had never functionally tested myself"=20 OR i could instead say: "Here, take this last known - good patch, which I tested last week and all = was working 100% fine with the log file, pid file, rc.d script, etc, etc=E2=80= =A6" So that's what I say / said. Please don't give me extra grief about it when= I wasn't the guy who fluffed it up. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-192347-13-Y1fcA0mQa1>