svn commit: r365590 - in head/cad/spice: . files

[Bryan Drewery]

On 8/21/2014 5:27 PM, John Marino wrote:
> 
> On 8/22/2014 00:12, Bryan Drewery wrote:
>> On 8/21/2014 5:09 PM, Hiroki Sato wrote:
>>> John Marino <freebsd.contact at marino.st> wrote
>>>   in <53F663B2.3000800 at marino.st>:
>>>
>>> fr> On 8/21/2014 21:41, Hiroki Sato wrote:
>>> fr> > Author: hrs
>>> fr> > Date: Thu Aug 21 19:41:06 2014
>>> fr> > New Revision: 365590
>>> fr> > URL: http://svnweb.freebsd.org/changeset/ports/365590
>>> fr> > QAT: https://qat.redports.org/buildarchive/r365590/
>>>
>>> ...
>>>
>>> fr> I'm sorry, but using freebsd-specific <bsd.prog.mk> in a ports vendor
>>> fr> makefile is NOT an improvement and frankly puts the build at risk on
>>> fr> DragonFly.
>>> fr>
>>> fr> I wish there was a rule that ports should not use system make fragments.
>>> fr>  This is not a good practice.  This port had a perfectly working and
>>> fr> generic makefile before.
>>> fr>
>>> fr> There's a good chance this just broke spice on DragonFly as the system
>>> fr> make file these are different.
>>>
>>>  I can understand that vendor's Makefile should be platform-neutral,
>>>  but I do not think there is advantage to maintain
>>>  ${FILESDIR}/Makefile in a way not to use FreeBSD-specific stuff
>>>  because it is used only by the port.  Should we care about build on
>>>  DragonFly?
>>
>> No! This is FreeBSD. Ports is only officially supported on FreeBSD.
>>
>> There are plenty of other ports using bsd.prog.mk.
> 
> Putting the first statement aside which frankly contradicts other
> statements made by other portmgr and completely belittles my
> contributions, this is a bad idea for FreeBSD too.  You are not
> containing the port to ports collection.  If the system makefile
> fragment changes, it affects the port. It's a dumb decision.  If you
> want these makefile fragments, put a tailored copy of Mk/
> 
> In this PARTICULAR case, I staged the port.  I fixed that makefile.  HRS
> changes serve no purpose other than to potentially break my work.
> Obviously that is not his intention, but that is the result.
> 
> Frankly he should revert this immediately.  It was working before
> everywhere.

This attitude is completely wrong. This is FreeBSD ports. You should not
be harping on people for writing to FreeBSD. Whatever bapt has told has
told you does not negate this. We support you using FreeBSD for dports
but the fact is that dports is a fork anyway. Nothing is stopping you
from modifying dports for these fixes where required.

It really is not okay to be giving people this sort of response.

Asking someone to use a more portable change for the sake of upstreaming
and use on DragonFly is fine. Screaming that they are are only changing
things to break your work is not, or that they are doing things wrong
when they are perfectly fine in the normal 20 year convention is not.
You, and possibly bapt, are the only committers who really care about
getting ports working on DragonFly. Please consider that next time you
bring it up. Others are offended by you demanding they change things or
that they did it wrong for DFLY.

Regarding this individual change, you have provided no evidence it
breaks anywhere. And as I've pointed out there are plenty of other ports
using bsd.prog.mk. 127 files reference it. It is perfectly reasonable
for someone to use bsd.prog.mk in ports.

> 
> John
> 


-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20140821/add565d8/attachment.sig>