Date: Fri, 1 Apr 2011 00:35:09 -0500 From: Zhihao Yuan <lichray@gmail.com> To: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> Cc: FreeBSD Ports <ports@freebsd.org>, Eitan Adler <eadler@freebsd.org> Subject: Re: Removing Cruft from the ports tree Message-ID: <BANLkTimDpi85WU=uLHbZCmkVyN8nYnwPgQ@mail.gmail.com> In-Reply-To: <AANLkTim7AqoJd%2BrGqeu6mw4iVazHupzR2HxbPGoQJv-n@mail.gmail.com> References: <AANLkTikmyPyY8q1xN47_dH3D6ndFoXYDaM3F%2BtWdFKe0@mail.gmail.com> <AANLkTim7AqoJd%2BrGqeu6mw4iVazHupzR2HxbPGoQJv-n@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 31, 2011 at 11:29 PM, Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> wrote: > On Thu, Mar 31, 2011 at 11:55 PM, Eitan Adler <eadler@freebsd.org> wrote: > >> Hi, >> >> =C2=A0 =C2=A0I=E2=80=99m been working recently on a series of PRs that c= alled =E2=80=9CReaper >> of the Dead=E2=80=9D PRs. I have been going through the various build fi= les we >> have (for source, docs, and especially ports) and attempting to remove >> dead code, old cruft, and unneeded checks. Some examples include >> ports/155543, ports/155511, ports/154395, conf/155737, and >> conf/155738. My goal has been twofold: making it easier to understand >> what is going on, and speeding up the process without requiring >> significant change. >> >> =C2=A0 =C2=A0One of the features that has given us the most trouble has = been >> the options framework for ports. We automatically test ports using the >> default options, but we are unable to perform automated using every >> combination of options. A port with just four options has sixteen >> possible configurations, and some ports have more than that. Even >> supporting one option might double the number of things to test. >> >> =C2=A0 =C2=A0However some ports rely on specific configurations of optio= ns of >> other ports. In order to deal with this mess we have come up with a >> hack: slave ports. We have entire ports that are designed just to >> change the default options for other ports. This requires a >> non-trivial amount of code on the bsd.*.mk files to support. >> >> =C2=A0 =C2=A0Automated configuration is not the only thing that has caus= ed us >> trouble in the past. We routinely have to do deal with questions from >> inexperienced users on questions@ and ports@ details problems with >> non-standard configurations. Many times the solution to a ports >> related problem is flipping a bit in the options file. >> >> > --------------------------------------------------------------- > > >> =C2=A0 =C2=A0I propose removing the options systems entirely. While it d= oes >> serve a small purpose of allowing customization for some end users, I >> believe the flaws outweigh the benefits. Removing the options >> framework would enable us to remove over 500 lines of expensive code >> from the ports system. Not only that but because maintainers would be >> able to choose the best possible configuration for the their port >> users would no longer have to mess around. >> >> > > > The idea specified above is really very good , because , during =C2=A0=C2= =A8make > install ...=C2=A8 > installations , given a ( non-tested previously ) improper selection > sometimes wasting important number of hours because at some point make is > producing an error . > > Sometimes , all of the options may work in the computer of the maintainer= or > tester because some required parts may already be present in their system= s . > When a user tries to install such a port into a new computer may lead to > failure because those different parts are not present in the new computer= . > Many times I am encountering that problem , and I wish that the maintaine= r > should test that in a CLEAN computer to encounter the same problem before > releasing the subject software . > > Actually , sometimes the options are really not necessary to ask because = to > use ( the port under work ) may use it , therefore why to ask about such = an > option : Instead of asking at least YES or NO , assume worst case as YES = , > and take actions with respect to this answer , or select the best default > and leave the other parts to be completed by the installer with respect t= o > his/her needs . > > When such an approach is used , ONLY a SINGLE case will be tested with > outcome as Success or Failure > which correction of problem in that case will be very easy by either > removing the optional part or making ready it . > > As said above , number of possible test cases is an exponential requireme= nt > such as > =C2=A0( Number of options to test ) to 2 ( at least when there are only Y= ES or NO > selections ) > which requires exponential work to test the possibilities . > > This is an enormous work requirement . It is obvious that the port > maintainers working hard to serve to the community . Instead of increasin= g > their work complexity from linear to exponential ( which is really an > unnecessary burden to them ) always we try to eliminate their burdens as > much as possible . > Whenever I adds an option to a port, I tests all of the combinations, with the related dependencies missing or met. Then I ask committers to test them in tinderbox. I think maintainer should take responsible for that, not the options system. Options do make sense. In some cases, one single options can eliminate/add over 50 dependencies, which save/waste all users' time. We maintainers/developers exists to save users' time. Not just the time to build ports! In a world without options, like Archlinux, just check its AUR repository -- one software may have 10 pages of different PKBGUILDs! Options significantly limit the increasing of the different package names. A good example of to make use of options is Gentoo's ebuild system. The USE_* flags are nothing new, but they are standardized. We may need to standardize our WITH_*/WITHOUT_* flags instead of giving a "commonly use flags" instruction. > > ------------------------------------------------------------------- > > >> =C2=A0 =C2=A0While I understand there might some minor part of the commu= nity >> that has a sentimental attachment to the blue-on-gray-on-blue >> configuration, and still others want to prematurely optimize, a simple >> workaround could be implemented. We can allow users to add their own >> ./configure arguments to the makefile. This serves the needs of the >> community while allowing us to deal with a simpler and more reliable >> ports system. >> >> =C2=A0 =C2=A0Feel free to express your thoughts here. I would like to ge= t this >> hashed out now so the process could occur on a later date(1). >> >> -- >> Eitan Adler >> > > > Thank you very much . > > Mehmet Erol Sanliturk > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > --=20 Zhihao Yuan The best way to predict the future is to invent it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimDpi85WU=uLHbZCmkVyN8nYnwPgQ>