Ciaran McCreesh <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 08 Sep 2008 23:13:25 +0100:
> On Mon, 8 Sep 2008 14:33:50 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: >> >> One of the great things about ebuilds is that they're very natural to >> write in most cases, if you can manage to build the program by hand. >> Raising this barrier of entry for questionable benefit seems like a bad >> idea. We don't need to make it any harder to begin contributing to >> Gentoo. Great point, Donnie. One of the things I've appreciated about the ebuild format is how accessible it is... in comparison to say some spec file. Part of that of course is that it's right out there in the open, not tied up in some semi-transparent tarball, but part of it is certainly that it's reasonably close to simple bash, as well. > So why are we making people know the exact ins and outs of > reimplementing default functions, complete with knowledge of whether or > not to use die, when all they need in most cases is to set a simple > variable instead? > > What proportion of people do you think know whether or not you need a > die with econf or emake? This is a valid point as well. However, for a user simply concerned with getting a functional ebuild so the package is tracked by the PM as opposed to not (or manually tracking with package.provided), an extra die or two, or even the lack thereof, and the docs and stuff, don't matter as much as something easily understood and written with little more than knowledge of bash and what's easily cribbed from a few existing ebuilds used as samples. These rather arbitrary vars do make sense to someone with a bit more knowledge, but are going to be about as opaque as the proper use of die, etc. What's worse, they make the simple-case ebuilds more difficult to crib from for the user-sysadmin simply interested in getting a functional ebuild that allows the packaging system knowledge of what he's installing. This sort of person is likely to write the ebuild, test it, and when it works, be done with it, regardless of its "correctness", and ideally with as little pre-supposed knowledge as possible. They don't care about dies, but will care if they have to spend another half hour diving into docs to figure out how to effectively translate the .configure --with/etc stuff into the appropriate vars. > The DEFAULT_* variables make it *easier* to write packages because half > the time you don't need to arse around writing src_* functions. Every > src_* function written by someone is another place there can be a > non-obvious screwup. That's true for the dev, certainly, but they do presuppose certain additional pre-knowledge that our user-sysadmin above won't have immediately. What's more worrying from the perspective of that person is that while all these new vars are optional, if devs (with that pre-knowledge) start using them as easier, pretty soon that person above isn't going to have any easily accessible simple ebuilds to crib from any more. It's not directly apparent that those vars hold what would be fed to .configure more or less directly, without knowledge of the package the ebuild is for. In ordered to get that knowledge, the newbie ebuild writer will be forced to either investigate the packages he's cribbing from the ebuilds of, or look up the PM/PMS/ebuild documentation. At least with eclasses, once one knows about inherit (a pretty simple concept once people start looking at ebuilds), it's standard bash functionality and easy enough to lookup what those arbitrary vars actually do. If we implement this, it's going to be locked away in the PM somewhere not so easily accessible. Additional specialized knowledge will be necessary. (Hmm... this argument went other than I intended. I was planning to point out that usage of the vars was optional, and that our user-sysadmin wouldn't have to use them if they didn't want to... but then as I wrote, I realized it may be optional, but that doesn't help much if all the simple ebuilds he finds to crib from end up using the pre-knowledge required vars, leaving him nothing simple to crib from without that knowledge. The accessibility level will have been reduced if this happens.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
