what I would love

Posted Jan 27, 2011 13:03 UTC (Thu) by pboddie (guest, #50784)
In reply to: what I would love by albertoafn
Parent article: Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

When I install an application I would love to have a standarized description with some vital information (at least what I consider vital)

Aside from completely independent sites such as Freshmeat which have been attempting to catalogue software for many years already, there has been a certain amount of movement towards augmenting the basic metadata within various services. I think that the Debian package archive's Web site now has screenshot support, for example.

That said, some of what you've mentioned is useful information, even that which isn't already recorded in some fashion.

I.e.:
- languages available
- dates (year of 1st release, date of 3 last updates)

The latter is just a matter of a repository search, more or less.

- version
- history (when applicable)
- dependencis (Installed and new)

All standard package metadata.

- works fine with gonme/kde/xcf/others
- cli? gui?
- related guis availables

Supported to an extent with metadata and "suggested packages".

- tasks that can be done with the program

To an extent, the Debian dependencies support this, although it's largely to do with whether a program provides the same facilities as another program.

- supported formats (when applicable)

Interesting!

- useful paths for the application (where the * is the config file? where does it save data by default, etc...)

This is a policy matter: the configuration files, for example, should all reside in a standard place such as /etc/sysconfig (or your distribution's alternative). It would be nice to be reminded of this via the package manager though...

dpkg --show-config-files <package>

- is it dead? (ie. is there any known ppl/team working on it? related pages? last time the repository version was update?... etc...)

More a searching or statistics gathering activity, like the frequency of releases mentioned above.

- description

Very standard metadata, this!

- a liltle video of the application working (if applicable, ie. games) and date/version the snapshot/video was done
- ... some extra stuff that is only applicable to some application but can be useful to know (ie: related projects, or special trick for that application) [...]

This is the sort of thing that Web site front-ends attempt to provide, even today.

All this can be of course be turn on or off (i.e simple or advance. Maybe some + to see more information for the app) Me, and I think most of us, would have their brains blown up by the awesome of a package system like this. And this little features are not hard at all to achive :)

Many of them are already there, so I'd rather have my mind blown by something else, really. ;-)

what I would love

Posted Jan 27, 2011 17:46 UTC (Thu) by albertoafn (guest, #64225) [Link] (1 responses)

     Aside from completely independent sites such as Freshmeat which have been attempting to catalogue software for many years already, there has been a certain amount of movement towards augmenting the basic metadata within various services. I think that the Debian package archive's Web site now has screenshot support, for example.

For me its not the same freshmeat and a repository. A repository has some sort of control over what i am installing. Not just random code (or at least that's what i'd like to think)

Debian has the screenshot support. It doesn't tell you the version of the screenshot tho :(

[...] Anyway, yeah, some of this information is already available. Usually the faster way to find out about it, it's find out the project homepage somewhere or google it and look for it there. That or a few commands to find out about this metadata, but with a generic form like this to fill in by maintainers would be much centralized and much of the data only has to be entered once...

This is for example where the large base of "noobs" users of ubuntu that everybody like to bash can come in handy to help gather all that data. Its not complicated data (NOTE: no offense intended. noob = not as savvy as other distributions. I know lot of people that use ubuntu that would love to collaborate but does not know much, even to triage bugs)

 This is a policy matter: the configuration files, for example, should all reside in a standard place such as /etc/sysconfig (or your distribution's alternative). It would be nice to be reminded of this via the package manager though...
dpkg --show-config-files package

I meant all kind of useful path or env variables, not just conf files. And yeah its a matter of the policy, but thats what they are trying to sort it out in this article, isnt it? :)

btw when i said history i meant changelog :)

Many of them are already there, so I'd rather have my mind blown by something else, really. ;-)

I agree that many are there, but not in a uniform accessible way. Id love to see all this things in a gui with the ability to sort the packages by these fields and compare between each other

And many of this would make more people to be able to use repositories. Yeah, nowadays I can tell my gf to look for photoshop or gimp and she is able to install it. But how can she pick her own packages without installing it and try a few out? with more metadata presented in a uniform way, she would start loving repositories as i do. (and id be useful for me too!)

I also agree that are lots of things to do. maybe more important. But I just wanted to share some pointers that I always thought could be very useful and easy to do now that this matter is argued :)

what I would love

Posted Jan 29, 2011 18:17 UTC (Sat) by pboddie (guest, #50784) [Link]

I meant all kind of useful path or env variables, not just conf files. And yeah its a matter of the policy, but thats what they are trying to sort it out in this article, isnt it? :)

It would be very useful to be able to query something and get this kind of information, although gathering it together in the first place would be some kind of documentation problem: the code surely knows which environment variables and configuration files to read, but this information has to make it out of the code and into some other kind of description.

I only refer to policy because this provides the basis of any decision about where programs should put their configuration files, for example. But then again, having tried to get packages into Debian and running into policy errors (and being told to read the somewhat unfocused set of manuals), I can totally agree with the idea of having tools that make such information more available to people who might not be familiar with "where things go".

I also agree that are lots of things to do. maybe more important. But I just wanted to share some pointers that I always thought could be very useful and easy to do now that this matter is argued :)

I think it's great to have these kinds of discussions, though. :-) And nicer front-ends to repositories - I can imagine something like a Web shop (but without any financial transactions, of course) - is probably something on my long list of things to play with... if I ever get the time.