Date: Sat, 14 Apr 2012 10:40:43 +0200 From: "Timur I. Bakeyev" <timur@FreeBSD.org> To: Doug Barton <dougb@freebsd.org> Cc: cvs-ports@freebsd.org, cvs-all@freebsd.org, ports-committers@freebsd.org Subject: Re: cvs commit: ports/net/samba34 Makefile ports/net/samba34/files samba.in ports/net/samba35 Makefile ports/net/samba35/files samba.in ports/net/samba36 Makefile ports/net/samba36/files samba.in Message-ID: <CALdFvJGDdqrsMy8zg8SdZvjC9ZZqC4%2B6HHM=7DCsc2OVSMiBxQ@mail.gmail.com> In-Reply-To: <201204130916.q3D9G0an068975@repoman.freebsd.org> References: <201204130916.q3D9G0an068975@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm really speechless... Do we, for fuck sake have any policy for updating ports which still do have alive maintainers? I was surprised to find out that Doug changed startup script in January without any notice, but now AGAIN!!! Not a note to maintainer, nothing - it's starts to become a tradition between ports commiters? This whole matter around port updates makes me really disgusted and kill all the willingness to do any port maintenance - if any one can come and screw up what ever you did, spending your precious time - whats the point to contribute at all? Really annoyed, Timur Bakeyev. On Fri, Apr 13, 2012 at 11:16 AM, Doug Barton <dougb@freebsd.org> wrote: > dougb =A0 =A0 =A0 2012-04-13 09:16:00 UTC > > =A0FreeBSD ports repository > > =A0Modified files: > =A0 =A0net/samba34 =A0 =A0 =A0 =A0 =A0Makefile > =A0 =A0net/samba34/files =A0 =A0samba.in > =A0 =A0net/samba35 =A0 =A0 =A0 =A0 =A0Makefile > =A0 =A0net/samba35/files =A0 =A0samba.in > =A0 =A0net/samba36 =A0 =A0 =A0 =A0 =A0Makefile > =A0 =A0net/samba36/files =A0 =A0samba.in > =A0Log: > =A0The samba rc.d script uses some clever tricks to start (up to) 3 diffe= rent > =A0services using the same script. As a result it resets rcvar several ti= mes > =A0in order to process the options for each service. > > =A0The changes I made on 2012/01/14 to facilitate the removal of set_rc_v= ar() > =A0from HEAD were effective in the case where the WINBIND option was off = (the > =A0case that I tested) because that causes the related portions of the rc= .d > =A0script to be removed completely on install. However, if installed from= a > =A0package, or installed using the the default OPTIONS, WINBIND is on, wh= ich > =A0caused the last known rcvar to be winbind_enable. > > =A0Since the common case seems to be for users to use samba_enable (which > =A0only enables smb_and nmb_ by default) the fact that rcvar=3Dwinbind_en= able, > =A0but that knob is off, caused the startup script to trip on a totally > =A0unrelated portion of rc.subr. > > =A0So the fix is to move processing of the winbind_ stuff first, which le= aves > =A0the last known rcvar as smb_enable. Since running nmb without smb is a > =A0very unlikely scenario, this should be safe for the common case, as we= ll > =A0as safe if the user enables winbind_. > > =A0Apologies all around for not catching this sooner, and thanks to the u= sers > =A0who reported the problem and stuck with me while I debugged it. > > =A0Bump PORTREVISION since this fix is needed for the common case, as > =A0configured for the package. > > =A0Revision =A0Changes =A0 =A0Path > =A01.14 =A0 =A0 =A0+1 -1 =A0 =A0 =A0ports/net/samba34/Makefile > =A01.6 =A0 =A0 =A0 +5 -5 =A0 =A0 =A0ports/net/samba34/files/samba.in > =A01.11 =A0 =A0 =A0+1 -1 =A0 =A0 =A0ports/net/samba35/Makefile > =A01.3 =A0 =A0 =A0 +5 -5 =A0 =A0 =A0ports/net/samba35/files/samba.in > =A01.6 =A0 =A0 =A0 +1 -1 =A0 =A0 =A0ports/net/samba36/Makefile > =A01.3 =A0 =A0 =A0 +5 -5 =A0 =A0 =A0ports/net/samba36/files/samba.in
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALdFvJGDdqrsMy8zg8SdZvjC9ZZqC4%2B6HHM=7DCsc2OVSMiBxQ>