Re: [gentoo-dev] The future of eclasses

[John Stalker]

I agree with almost all of this, but I would like to add one additional
point.  It's not solely a matter of encouraging users to contribute
ebuilds, but also of allowing them to understand them.  I want to
understand what will happen when I type emerge foo/bar before I
actually do it.  This is what always annoyed me about rpm and
deb.  There are two ways of dealing with this.  One is to keep
everything in a familiar format, ie bash for gentoo portage or
Makefiles for FreeBSD ports, and the other is to have a stable
well-documented interface to some mysterious black box.  I would
much prefer the former wherever it is feasible, but of course I
don't have the burden of maintaining large numbers of ebuilds.

> > This is all almost certainly portage v2 stuff. However I'd like everyone
> > working on portage (e.g. Bevin, with whom I've spoken) to know where we
> > stand, to coordinate our efforts. As always, any ideas, forecasts,
> > suggestions etc. are always welcome.
>
> I like the idea. If its documentation becomes part of the ebuild howto,
> it will get adopted fairly quickly.
>
> The main concern Hallski and me (and possibly others, such as John
> Stalker, if memory serves) was that the current ebuild system mirrors
> the manual build process so closely that external contributors have
> little or no difficulty sending us ebuilds.
>
> I think this can be solved somewhat if it is clearly documented _what_
> is assumed by the various eclasses and perhaps a motivation when the
> assumptions are less than crystal clear.
>
> What plagues many non-kde ebuilds is that their build systems are fairly
> non-standard. And even packages with seemingly standard build systems
> quickly turn out to have both minor and major flaws (Mailman is a good
> example of a horrible build system that on the surface looks nice, but
> in practice turns out to be a real bitch).
>
> The minor nuisances of the various build systems mean that we might find
> it easier to patch the generated Makefiles instead of the Makefile.in or
> Makefile.am files, thus requiring an intermediate step between
> configure and make (ie, patching in src_unpack is too troublesome).
>
> Consequently a simple wrapper for src_compile will only work a certain
> percentage (possibly relatively low; <= 50%) of the time, and a
> full-blown manual src_compile() function must be written for the rest of
> the ebuilds.
>
> The situation for src_install() is even more dire, as it would appear
> that close to all packages have trouble conforming to any kind of FHS,
> and installing in a temporary directory is completely foreign.
>
> Now, for our regular ebuild writers, the 50% saving is a big deal. For a
> new submitter, it means he has to figure out which eclasses are
> available (+ what they are), which criteria his package must meet to be
> able to avail himself of the various eclasses, and finally test that
> this is really so.
>
In conclusion, I am very positive about eclasses for our regular
> contributors; it would possibly give us yet another advantage to our
> package system that would allow us to add more ebuilds more quickly (one
> could argue that quantity in itself is not a good thing, and of course I
> agree ;). But if our intention is that "regular" users should easily
> be able to submit ebuilds, and more easily so than writing a debian
> package or an rpm spec, then we must be very careful to consider the
> result eclasses have on our "regular" users.
>
> </rant>
>
> Kind regards,
>
> Karl T
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@g.o
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

--
John Stalker
Department of Mathematics
Princeton University
[phone]