On Thu, Mar 31, 2011 at 11:29 PM, Mehmet Erol Sanliturk <m.e.sanlit...@gmail.com> wrote: > On Thu, Mar 31, 2011 at 11:55 PM, Eitan Adler <ead...@freebsd.org> wrote: > >> Hi, >> >> I’m been working recently on a series of PRs that called “Reaper >> of the Dead” PRs. I have been going through the various build files 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. >> >> One 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. >> >> However some ports rely on specific configurations of options 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. >> >> Automated configuration is not the only thing that has caused 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. >> >> > --------------------------------------------------------------- > > >> I propose removing the options systems entirely. While it does >> 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 ¨make > install ...¨ > 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 systems . > 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 maintainer > 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 to > 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 requirement > such as > ( Number of options to test ) to 2 ( at least when there are only YES 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 increasing > 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. > > ------------------------------------------------------------------- > > >> While I understand there might some minor part of the community >> 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. >> >> Feel free to express your thoughts here. I would like to get 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-unsubscr...@freebsd.org" > -- Zhihao Yuan The best way to predict the future is to invent it. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
