Date: Sun, 03 Aug 2014 14:57:20 +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-HmJ1ik9GBV@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 #7 from John Marino <marino@FreeBSD.org> --- (In reply to dreamcat4 from comment #6) > 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 questio= n. When you said "auto-generated" do you mean "make makeplist"? Because it ju= st assigns all of the @dirrmtry and expects you to fix them (per the comment on the first line). > If the user has modified of put something of their own files there.=20 This is not allowed nor expected. pkg is not expecting any file that it installed to be modified nor extra files to be put in its dedicated directories. It will spew errors upon deinstall if this happens. /usr/loc= al is supposed to work as if it's mounted ready only > So how > is docs directory different? Also: that only matters IF the contents of t= he > directory has been added to somehow. But the files put in there are static > and we would not expect the directory to be non-empty. I just don't get i= t. What don't you get? There is a packing manifest. It removes all the files in the directory and then unconditionally removes the directory. Unless the directory is shared with one or more ports (e.g. fonts, desktop icons, etc) then you unconditionally remove it and you want to see an error occur if it's not em= pty (because it's expected to be empty upon deinstall) @dirrmtry is an exception, @dirrm is normal > > DISTFILES=3D UMS-${DISTVERSION}.tgz > >=20 > > That's equivalent. You could have also defined USES+=3D tar:tgz though= and > > gotten rid of the extract suffix >=20 > Yes it is. It also adds an extra line / variable to the port Makefile for= no > apparent reason whatsoever. I don't know what you mean by this. Your change was okay, it's a bit clean= er, it just didn't fix anything. > > I haven't see the rc script, maybe all it needs is > > "var/run/universal-media-server" hardcoded to it. That actually sounds= like > > an oversight that needs fixing. Most of the other stuff I don't see as > > mistakes. >=20 > Yeah maybe. But there were no guideline for that in Porter's Handbook (th= at > 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 change was introduced. I suspect there was an error that needed fixing, and the commit just simpli= fied this at the same time. Personally I also prefer the hardcoding to an unchanging variable. > In the Porters handbook it says to run "make stage" and not "make stage-q= a". > So now I know that is possible, I can just run manually and don't need > Poudriere at all (thank god). OUTPUT BELOW: well, no, it's not a replacement for poudriere. Particually it will not ca= tch file system violations or missing dependencies. But it will check plist issues. > 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 hmm, what? It didn't do anything.=20 try make clean ; make stage ; make stage-qa > Again, I say, "works fine". But heh. Now you guys have broke the rc.d scr= ipt > you expect me to fix it? Reality check. No, you would be expected to make a comment on the PR that broke script and say, "hey the script is broken". Then the committer will likely fix it. > 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 h= arm > 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 c= an > be re-done right the next time. Whatever. I think you are missing the point. You are attempting this: 1) Update the port version [ok] 2) Fix the script problem without saying that's what you're doing, and the = way you did it is probably wrong because it reversed what the previous committer did. I guarantee you he had a reason for making the change, so putting it = back to your original proposal raises flags immediately, especially given the previous committer runs his changes on 8 poudriere jails (i386, amd64 x Fre= eBSD 8, 9, 10, head) What this should have done (IMO) is only update the port and fix the script issue.=20=20 > 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.=20 I'm not going to fix it at all, I'm the triage guy. > But further than that you > will just loose my future contributions to FreeBSD project. I just don't > have time 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 softwa= re > itself. So you are going to state that an contributer with very little experience a= nd one that is unable to use poudriere on a single platform to check his submission makes no mistakes and can declare what is useless and petty to experienced committers than have to run these works through several builder= s.=20 It takes use years to learn all the things but you've got it down in 2 week= s, that's awesome. I've asked the previous committer to review your PR. If he does, he can te= ll you why the plist was changed. --=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-HmJ1ik9GBV>