Date: Fri, 22 Aug 2014 08:47:50 +0200 From: John Marino <freebsd.contact@marino.st> To: Hiroki Sato <hrs@FreeBSD.org>, marino@freebsd.org Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org, bdrewery@FreeBSD.org Subject: Re: svn commit: r365590 - in head/cad/spice: . files Message-ID: <53F6E796.7090707@marino.st> In-Reply-To: <20140822.140157.2098353200954412611.hrs@allbsd.org> References: <20140822.070939.1253386656808735449.hrs@allbsd.org> <53F66EE5.7080500@FreeBSD.org> <53F6724A.6000602@marino.st> <20140822.140157.2098353200954412611.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/22/2014 07:01, Hiroki Sato wrote:
> John Marino <freebsd.contact@marino.st> wrote
> fr> Frankly he should revert this immediately. It was working before
> fr> everywhere.
>
> I take the maintainership because I have plans to add further changes
> to this port. Like the other change I committed just now, they will
> be ones primarily for supporting new devices. Probably I will change
> files/Makefile further.
>
> I changed files/Makefile not to use bsd.prog.mk as I understand that
> your criticism was based on the use of it. However, still I do not
> understand what exactly you are pointing out by words "break my
> work". I used bsd.prog.mk just because it was handy, so if my change
> was inappropriate I will consider fixing. You first mentioned the
> breakage was on DragonFly but you did not give specifics. If someone
> will be happy by changing something, please provide enough
> information.
First, thank you for using an alternative method. I am happy that you
have an interest in improving spice and that you are the new maintainer.
At at academic level, a port relying on a makefile fragment not
controlled by the ports collection is a bad idea. Yes, other ports do
it and yes changes only happen per release and yes, changes rarely
happen at all. It's still not a good idea.
The dragonfly and freebsd sys/mk have a similar function and once were
the same. However there are differences. As a specific example.
although ports-mgmt/pkg was developed specifically to support DragonFly,
we can't install it without patches because their internal makefile uses
system mk files and causes some files not to get installed.
I also have a "back burner" goal of putting ports on Solaris-based
machines (illuminos too) which are completely dissimilar. Spice would
have no hope in that case. I haven't worked on the "sun-ports" because
I've been too busy helping staging ports, something that doesn't
directly benefit dports.
> My opinion about using bsd.prog.mk is as follows. DragonFly's
> bsd.*.mk should be based on FreeBSD's and I believe my change has
> been compatible for over 10 years.
There is significant divergence after 10 years.
> When a vendor-supplied Makefile is not reliable, I usually avoid to
> create a hand-rolling install target including lines of "install foo
> ${PREFIX}/bin" since maintenance is hard for me. Although there are
> some in ports I am maintaining that have such an install target, they
> suffer from changes to the ports tree. When staging support was
> added they became broken and needed to add ${DESTDIR} or ${STAGEDIR}
> manually, and -j# support for such kind of install targets is
> sensitive to () as tijl@ explains. Macros in bsd.prog.mk (and
> bsd.files.mk) are safe at least with regard to them.
I would have no issue with this if a tailored copy of system mk files
were placed in /usr/ports/Mk somewhere. It would even be a good idea.
> I do not insist that bsd.prog.mk is free from compatibility issue
> even in FreeBSD you mentioned. However, I personally believe risk of
> using it is smaller than (or as small as) one of hand-rolled target
> because I eventually needed to fix Makefiles before as explained
> above. Thus, I do not either recommend or deny using bsd.prog.mk,
> while I use it in ports I maintain. I just think the risk is small
> and I can fix it if there is a problem because I am the maintainer.
Since there are "only" 127 ports that visually use this (but likely
more, e.g. pkg's use is not greppable), I think it would be feasible to
put a version of these makefile fragments in /Mk and convert the ports
to use those. I understand the benefits they can offer.
Thanks,
John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F6E796.7090707>