[CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program

Bryan Drewery bryan at shatow.net
Sat Oct 27 14:32:36 UTC 2012


On 10/27/2012 8:23 AM, Chris Rees wrote:
> [trim CC list a little to stop people regretting replying to this thread]
> 
> On 27 October 2012 10:15, Chris Rees <utisoft at gmail.com> wrote:
>>
>> On 27 Oct 2012 00:35, "Simon J. Gerraty" <sjg at juniper.net> wrote:
>>>
>>>
>>> On Fri, 26 Oct 2012 22:02:00 +0100, Chris Rees writes:
>>>> In that case we have a switch time on the order of years, not weeks; 8.3
>>>> is
>>>> supported until May '14, and unless we get a :tl etc MFC into 8, even
>>>> longer.  All this time the ports tree must work with pmake.
>>>
>>> I'm pretty sure I was told it is already in 8 and 7
>>
>> Not in 8.3 at least:
>>
>> svnweb.freebsd.org/base/releng/8.3/usr.bin/make/var.c?view=log
>>
>>>> I don't want to discourage you or belittle your excellent work here, but
>>>> Marcel made me very nervous with his comment on the process being "a few
>>>> weeks".
>>>
>>> That was based on discussions at the last devsummit.
>>
>> These discussions need backing up with a real roadmap, including detail on
>> exactly what 8.3 and 7.4 users will have to do to ensure that the ports tree
>> still works.
>>
>> I don't see where these considerations have been made.
> 
> OK, so how about this.
> 
> We (ab)use the security update mechanism to merge the pmake changes
> (:tl and :tu) into releng/7.4 and releng/8.3 (possibly the earlier
> releng branches such as 7.3, 8.2, 9.0).  We could then send out a
> message on ports-announce, giving a few weeks' notice that the change
> to bsd.port.mk is going through and that users need the latest
> 'security' patches.

This "weeks" is making a assumptions that users 1. reads ports@ or 2.
Update to security/errata patches in a timely manner or 3. Read UPDATING


> 
> When we change bsd.port.mk over, include a snippet such as the one at
> [1], which gives more informative error text and refers user to
> documentation.
> 
> Although I still think this is less than ideal, it is the only way I
> can see that we can switch before May '14, if the urgency is there.
> 
> Chris
> 
> [1] http://www.bayofrum.net/~crees/patches/bmake-pmake.diff
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 



More information about the freebsd-hackers mailing list