Providing more information to users about a package

Colin Guthrie gmane at
Sat May 24 16:52:11 PDT 2008

James Westby wrote:
> We could draw up a standard way to make this information available,
> and then ask upstream projects to do so. It would obviously take
> a while before it is available for a large number of packages.

I think this sounds like a really good idea.

Some immediate thoughts that spring to mind:

1) A standard way of taking the homepage URI and adapting it to extract 
the package info sounds like a sensible approach at first. This would be 
similar to the (admittedly rather crappy) favicon.ico approach in web 
browsers to display the little icon (I know there are more appropriate 
ways to do this now in the HTML head). The argument that some projects 
do not have control over their homepage is a fairly good one, but major 
hosts like sourceforge would no doubt add support for this format if it 
was to become popular. That said, it's probably quite complicated to 
mangle the homepage URL so that this metadata can be grabbed, especially 
when GET args make up part of the homepage URL...

2) Allowing individual projects to host their own screenshots and 
perhaps a longer description etc. is a great idea dn distributes the 
storage and bandwidth costs nicely. That said they are not going to be 
impartial (having a bias is to be expected) about their app and if 
reviews/popularity information is to be part of this, then it doesn't 
really make sense to start off on a distributed system when a central 
one would be able to provide a slightly more impartial slant and 
ultimately better information to users.

With those two thoughts in mind, I wonder if a cross distro sponsorship 
to expand an existing system is a better option? The most obvious one 
that springs to bin is It already carries a lot of information 
about many open source projects and has a strong community both by 
developers and users. It would make sense to add the ability to upload 
screenshots etc (does it do this already? I can't remember off hand).

Not to associate a project with it's Ohloh "homepage" could be done in 
two ways. 1) define a new field/tag/whatever in the various package 
formats (we all have "Homepage" so we could add "Project Page" too. This 
homepage would just be a metadata source XML file so the use of Ohloh 
wouldn't be mandatory, but I think it should be encouraged due to the 
impartiality reasons outlined above. I've found the Ohloh people quite 
approachable in the past so it's almost certainly worth running past 
them if other people think it's a good approach.

Just some idle thoughts before I hit the hay for the night.

Take care


More information about the Distributions mailing list