List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Friday 02 April 2004 20:43, Chris Gianelloni wrote:
> Anyway, for now it is much simpler to have a tree of ebuilds which are
> easily maintainable than a single (or a few) large xml files which would
> become a maintenance nightmare for all the developers involved.
> Currently there are many developers who work on only one ebuild in a
> particular area. As a good example, I maintain exactly one ebuild in
> app-emulation. What kind of separation would there be for the xml
> files? How would different versions be accommodated? Unless there was
> some "magic" which translated the text ebuilds/eclasses/profiles into
> xml (or a db, or whatever) before it went out to the world, and which
> *didn't screw up* in the process, I don't think we'd see much of a
> change any time soon. Not to mention the amount of work that would need
> to be done to portage itself to modify it to parse xml. I know that
> this sort of thing has been discussed before, and if memory serves me
> correctly, the reason for not doing so was not so much it being a bad
> idea or anything but really a matter of developer resources and
> energies. There's really nothing wrong with the current approach that
> would be helped by having the portage tree be in xml or a database, at
> least, not anything worth spending the tremendous amount of resources on
> that it would take. Personally, I would rather spend my time fixing
> bugs and adding new features to portage, not redoing all of the work I
> have done up until now to make it xml compliant.
I agree. The only feasible option that could have some benefit (which doesn't
mean I support it) is to make ebuild files selfcontained. There would be some
benefits in that, but there is a lot that is more important than even
considering that option.
Paul de Vrieze