[Slapt-get-devel] Feature suggestion - Source descriptions
aj at getopenlab.com
Wed May 10 05:48:04 EDT 2006
Hiya Jason et. all.
As some of you know, I'm CSA of OpenLab, which in turn develops one of the
distro's that include slapt-get/gslapt as default package/update manager.
We have begun work on the new 4.1 release. While reviews of the 4.0 version
was very good, one consistent complaint was still about package management.
The major problems there were however all with external package sources. At
the same time, we are a small company simply do not have the resources to
maintain our own QC'd tree of every slackware package out there - in fact
this is a core reason why we maintain binary cross-compatibility.
So now, the thought occurred to me that the ideal default setup would be to
have only our own package sources ENABLED but to include a number of the good
package sources such as OCSID and linuxpackages in disabled status so users
can enable them at their own peril. This is quite similiar to the default
state in which distro's like ubuntu now ship - world is not available unless
So far so good - but what would be really good is if the sources screen had
some way to show a "help" or "description" option for a source, that way
users could quickly learn what the source actually is.
The way I see it it would need a way to specify an html file/URL in the config
file. This should be optional however so that backwards compatibility is
So when a user clicks the description button, what should happen is:
1) Check if a file/URL is specified. If so then open that in the default
2) If not, check if $SOURCEURL/README or $SOURCEURL/README.txt exists (that
will cover all slackware mirrors) - if so, open THAT in a browser
3) If not, open the $SOURCEURL itself in a browser so the user can view the
tree itself - which will hopefully contain some sort of description.
This way I believe that you will get maximum capability without breaking
compatibility with any source.
If that is not feasable, even just a "browse source" button would be good, so
the user can get a feeling of what to expect from the source before deciding
if he wishes to enable it.
Although I am not a gnome developer I am very happy to help with implementing
this if I can have some pointers about where to look.
"80% Of a hardware engineer's job is application of the uncertainty principle.
80% of a software engineer's job is pretending this isn't so."
Chief Software Architect
http://www.getopenlab.com | +27 82 726 5103 (South Africa)
http://www.silentcoder.co.za | +55 118 162 2079 (Brazil)
More information about the Slapt-get-devel