Providing more information to users about a package

Nirbheek Chauhan nirbheek.chauhan at gmail.com
Sat May 24 11:47:08 PDT 2008


On Sat, May 24, 2008 at 8:46 PM, James Westby <jw+debian at jameswestby.net> wrote:
> Hi all,
>
> I'm at the airport on my way back from UDS. One of the sessions we
> did there was a phone conference with Richard Hughes (on Cc) about
> PackageKit. We got on to talking about wider issues, including how to
> provide more information about a package when a user is thinking about
> installing it, including things like screenshots.
>
> It would be great to do this in a cross-disto fashion, as most of the
> information is going to work for everyone. Obviously there are things
> like the theme used in screenshots that will change this, but perhaps
> it is not so important.
>
> One possibility is for us to just get all this information and stick
> it on a server somewhere, and then make the tools retrieve it as needed.
> However, this would probably be a lot of data, and may also have
> a lot of users retrieving it.
>
> Debian now has support for a "Homepage" field in debian/control, and
> I'm told that rpm spec files also contain this information. My
> suggestion was to use this, and have the upstream projects provide
> everything that we need, distributing the problem.

Gentoo has supported storing (in ebuilds) and displaying (while
searching for a package) a project's homepage for a while now, and the
way the ebuild format is structured, adding a "GUIDE" or similar
variable should be easy enough to implement (as one way of storing
this information). OTOH, there is also a metadata.xml for each
package, which might be a better candidate for storing this kind of
information.

**The following is relevant only to people familiar with the portage
tree format**

Advantages of using metadata.xml over a variable in the ebuild:

1) Does not require many changes to the package manager
2) Since there is no mangling of the ebuild format, one does not have
to resort to EAPIs
3) The above two also result in faster propagation of the feature
4) Parsing XML is easier and faster than sourcing bash scripts (purely
technical)

Disadvantages:

1) Portage does not parse metadata.xml (afaik), so this information
will have to be used by external tools such as eix, GUI installation
tools (like porthole, himerge), etc.

-- 
~Nirbheek Chauhan


More information about the Distributions mailing list