Re: [gentoo-dev] additional files in portage tree [Improving Portage]

[Aron Griffis]

Karl Trygve Kalleberg wrote:	[Fri Aug 10 2001, 02:18:11PM EDT]
> The problem with not using XML is that we have to make yet another file
> format parser, which we will have to maintain.
>
> What's more, for other people to be able to make use of the description
> files, they'll have to concoct their own parsers or use ours. If we want
> them to use ours, we will have to make bindings for it to Perl, Python,
> C, C++ and Java, preferrably other languages as well.
>
> We get all this for free when using XML, since it's widely supported by
> all non-trivial (and many trivial) languages.
>
> However, it's a pain in the butt to write/edit and to some extend more
> difficult to read than a format tuned for human reading.
>
> This is a known problem with no perfect solution. In fact, XML (or S-exp)
> is as close as we've gotten to date.

How hard could it really be to simply fill in an XML template?  Seems to
me that most package description files will be created by copying one
from another package, the modifying to suit the new package.  That
doesn't sound difficult at all.

An additional win with XML description files is that they can be read
and rewritten easily by automated tools (without YAFFP, as you
mentioned).  This becomes important when a new potential field is
created for the description files.  A tool can scan over the portage
tree, snarf in each description file, and spit out a new one with the
additional field.

Why would we do this?  To maintain the fill-in-the-template approach...
The next time the package is revised, the author would undoubtedly
notice the empty item in the description file, and presumedly would fill
it in.

> In my opinion, we really attack this problem from the completely wrong
> end: we start by describing not only tools/technology we want to use,
> but also the specific storage of the data before we even know what we
> want to extend Portage with in the long term.

Agreed.  What follows are my gut responses to your list.

> Better package descriptions is just one little part of it all. We also
> want a graphical package tool,

IMHO, this can wait.  A front-end text-based tool is sufficient for the
moment.  Attempts at graphical front-ends for either debs or rpms have
largely resulted in implementations that lag behind the text-based
tools.

> bug reporting,
> feature requests,

There are free web systems for managing these.  Why would they be
integrated into the portage system?

> regression testing,

This isn't a package management activity, but something that can be
handled on the individual package level.  Portage would be the wrong
place to implement this since the regression testing needs to be sent
back upstream to the package maintainer.

> an automatic package verifier that catches many of
> the nasty things (like ebuild foo install installing in /usr instead
> of ${D}/usr),

The correct solution to this is to run the install portions of an ebuild
with reduced permissions.  I realize this has issues, though.  I assume
that's why it's not in the system yet, but I think of everything
mentioned here, it's the most important.

> bindings/exports of the package database to tools
> outside Portage, etc, etc.

Indeed this is important.  (Sorry to be in disagreement on the other
points.)

> We seem to be at a stage where our entire user population is extremely
> well-versed in unix, have a lot of experience to bring to the table,
> and are prepared to suffer some major restructurings in vital parts of
> the system (mainly Portage).
>
> If anybody have any thoughts on this, we should get them all out now.
> I'll try to maintain them in some form for design document on the
> gentoo.org.

Great!

Aron