Date: Tue, 12 Feb 2013 08:59:00 +0100 From: 'Baptiste Daroussin' <bapt@freebsd.org> To: Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au> Cc: ports@freebsd.org Subject: Re: [CFT+BRAINSTORM] One USE_ to rule them all Message-ID: <20130212075900.GA12760@ithaqua.etoilebsd.net> In-Reply-To: <22320519B33A4AB9AB68DC7C4BB84765@white> References: <20130204181946.GF67687@ithaqua.etoilebsd.net> <77AC0D5229B747E1B7A7171E84BB8C7F@white> <20130211143553.GA4326@ithaqua.etoilebsd.net> <22320519B33A4AB9AB68DC7C4BB84765@white>
next in thread | previous in thread | raw e-mail | index | archive | help
--ReaqsoxgOBHFXBhH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 12, 2013 at 04:13:19PM +1100, Dewayne Geraghty wrote:
> > -----Original Message-----
> > From: owner-freebsd-ports@freebsd.org=20
> > [mailto:owner-freebsd-ports@freebsd.org] On Behalf Of=20
> > 'Baptiste Daroussin'
> > Sent: Tuesday, 12 February 2013 1:36 AM
> > To: Dewayne Geraghty
> > Cc: ports@freebsd.org
> > Subject: Re: [CFT+BRAINSTORM] One USE_ to rule them all
> >=20
> > On Mon, Feb 11, 2013 at 09:21:47PM +1100, Dewayne Geraghty wrote:
> > [...]
> > > >=20
> > >=20
> > > Baptiste,
> > > The original question is a functional change to Mk/*, which seems=20
> > > beneficial. The specificity of USE_FEATURE is in keeping with the=20
> > > long term goal of "> The very long term goal will be to=20
> > switch as much=20
> > > code as
> > > > possible to be turn into a feature (when it makes sens of course)"
> > >=20
> > > A generic use of "USE" makes less clear for those=20
> > developers and users that are familiar and maintain=20
> > USE_${FEATURE} in their port.
> > > I appreciate the improvements that are being made, but=20
> > small steps are=20
> > > easier for the large numbers of people that are familiar=20
> > with the existing system.
> >=20
> > What is your suggestion, about the name of the macros, then?=20
> > concerning the small steps, that is the plan, convert things=20
> > small steps by small steps into features.
> >=20
> > >=20
> > > Also are their any foreseeable adverse side-effects of=20
> > making this change? =20
> >=20
> > Not that I know, and noone pointed me to an adverse side-effetcs yet.
> >=20
> > regards,
> > bapt
> >=20
>=20
> My suggestion regarding the name of the macros is to retain the original =
concept that you proposed, which is about centralising
> USE_<FEATURE>, rather than change the name as well as centralising functi=
onality. Moving the function of an existing name makes it
> clear what is changing; so please retain USE_$FEATURE.
I don't get what you expect here, do you have an example?
>=20
> I think a collaborative expectation is a fair assumption. You'd mentione=
d a long-term plan, perhaps that is something that also
> needs to be shared, so folks can take in the big picture and consider the=
issues as a whole - which implies a well advertised review
> window.
Well the long term plan has been mentionned in the first mail, it is to slo=
wly
get rid of the large and complex bsd.*.mk as much as possible to favour to =
the
new load-on-demand features, only loading and parsing what is needed might =
help
a lot improving the speed of the make(1) operations in the ports tree.
>=20
> As a project that changes infrastructure, it goes without saying that bre=
aking existing infrastructure should be avoided. We should
> be able to forsee the impact of change and provide scripts/src that make =
the migration smooth and seemless, possibly overlap
> functionality during a transitionary phase. =20
Yep and most of the time nothing of that case would be necessary it will be
seemless, in fact for now I can't see something that won't be seemless, but=
sure
if one happen then there will be scripts/exp-runs everything need to get the
migration as smooth and seemless as possible.
>=20
> After performing a cursory review and search for USE_$FEATURE under /usr/=
ports/security, where there are 89 unique instances of
> USE_$FEATURE from:
> grep USE_ /usr/ports/security/*/M* | cut -d: -f2 | cut -d=3D -f1 | grep ^=
USE_ |sort | uniq;=20
> It seems that there's going to be a lot of work by a lot of people, some =
requiring co-ordination. So, some questions about the
> process, rather than just the work:
We might give blanket to committers to change the ports to use features (wi=
th a
kind heads up to the maintainer of course) to help speeding up the migratio=
n.
> 1. How do you envision the change to occur - will the changes be collated=
and deployed in one hit, or staggered over a long period
> of time, like optionsNG? =20
Like optionsng but more except for probably touch ones (I don't have one in
mind yet :))
> 2. Will or should the ports be frozen or snap-shotted in entirety to avoi=
d maintenance effort by people that use ports, rather than
> maintain them?
The migration should have no effect on users as a new feature can only hit =
the
tree if there is a migration path with compatibility. And given that featur=
es
are not as exposed to users as options framework can be, most users may not=
even
notice :)
> 3. When will the change activity commence?=20
As soon I have finished my exp-run on with the first features (gmake, iconv=
and
motif might be the first one)
>=20
> Baptiste, you have been prompt and enthusiastically helped people with is=
sues with optionsNG; and I appreciate the improvement to
> our infrastructure that you've made.
Thank you.
regards,
Bapt
--ReaqsoxgOBHFXBhH
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlEZ9kQACgkQ8kTtMUmk6Eze1ACeLPaX3Dukejus7URBXi1544fA
gRIAnRwfboOkNdMPKX/TqtiNKSHTaBD3
=/R/B
-----END PGP SIGNATURE-----
--ReaqsoxgOBHFXBhH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130212075900.GA12760>