[Bug 192347] [maintainer update] multimedia/universal-media-server: Update to 4.0.1 + FIXES

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192347

--- Comment #17 from dreamcat4 at 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 tested
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 'ums'
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... Put
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 
* the guy who committed them made a boo-boo and didn't really do it properly. 

Then I can't seriously be expected to say "just continue to do it HIS way and I
assume it'll all be fine,"

"well probably, since that was some new configuration i had never seen before
and had never functionally tested myself" 

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…"

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.