Date: Sun, 03 Aug 2014 14:32:49 +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-KB8jUy7tqY@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 #6 from dreamcat4@gmail.com --- (In reply to John Marino from comment #5) > how is this change correct? > %%PORTDOCS%%@dirrmtry %%DOCSDIR%% >=20 > You'd better be able to remove that directory without question, so dirrmt= ry > is wrong if it's not being shared with another port (which is rare) I'm not sure I agree. The original entry is auto-generated. In other directories (which are not docs stuff), they don't remove without question.= If the user has modified of put something of their own files there. So how is = docs directory different? Also: that only matters IF the contents of the directo= ry has been added to somehow. But the files put in there are static and we wou= ld not expect the directory to be non-empty. I just don't get it. > DISTFILES=3D UMS-${DISTVERSION}.tgz >=20 > That's equivalent. You could have also defined USES+=3D tar:tgz though a= nd > gotten rid of the extract suffix Yes it is. It also adds an extra line / variable to the port Makefile for no apparent reason whatsoever. > this stuff: > @exec mkdir -p %%UMS_PROFILE_PATH%% >=20 > is wrong. it could be 8 levels deep since it's a variable. You only > attempt to remove one level. But you've defined it unconditionally as Ah OK then. > /var/run/${PORTNAME} so what purpose does having it as a PLIST_SUB have? = I > don't see one. Used by rc.d script (like I mentioned just in my previous comment). > I haven't see the rc script, maybe all it needs is > "var/run/universal-media-server" hardcoded to it. That actually sounds l= ike > an oversight that needs fixing. Most of the other stuff I don't see as > mistakes. Yeah maybe. But there were no guideline for that in Porter's Handbook (that= I could see)> And as the variable that is set in Makefile is currently set to= be "/var/run/..." then functionally there is was no error at the time this cha= nge was introduced. > - Again, redports < poudriere. You can pass in redports and fail poudrie= re. > - that implies you already ran make stage-qa which is good. That's the > check that's missing from redports In the Porters handbook it says to run "make stage" and not "make stage-qa"= . So now I know that is possible, I can just run manually and don't need Poudrie= re at all (thank god). OUTPUT BELOW: ums4 universal-media-server/ root~# make stage-qa =3D=3D=3D=3D> Running Q/A tests (stage-qa) ums4 universal-media-server/ root~# echo $? 0 ums4 universal-media-server/ root~# head Makefile=20 # Created by: Dreamcat4 <dreamcat4@gmail.com> # $FreeBSD: head/multimedia/universal-media-server/Makefile 361621 2014-07-= 12 15:22:00Z pi $ PORTNAME=3D universal-media-server DISTVERSION=3D 4.0.1 CATEGORIES=3D multimedia MASTER_SITES=3D SF/unimediaserver/Official%20Releases/Linux DISTFILES=3D UMS-${DISTVERSION}.tgz MAINTAINER=3D dreamcat4@gmail.com Again, I say, "works fine". But heh. Now you guys have broke the rc.d script you expect me to fix it? Reality check. I worked very hard creating this port. Most of the minor and utterly inconsequential changes you guys have made on top of that were fine. No harm done. But not this last one. It had problems and you should realise that the patch I offered now at least functionally fixes things for now. So they can= be re-done right the next time. Whatever. If you want to fix 'your way' because you think my ways wasn't good enough = to begin with then by all means please go ahead. But further than that you will just loose my future contributions to FreeBSD project. I just don't have ti= me for such pettiness / arguing for no benefit to end users. It's not going to improve their lives, in terms of the functionality of the software itself. You guys have a right to protect your platform, but I just don't see that happening here. --=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-KB8jUy7tqY>