[suggest] Re: [packagers] Re: RPMforge invitation
dag at wieers.com
Wed Jun 1 07:59:22 CEST 2005
On Tue, 31 May 2005, Avi Alkalay wrote:
> I don't know if this is the cerne of the discussion, but I think RPMForge
> should be stupid-users-oriented.
> More than a simple repository for RPMs, it could be an index for general
> apps dumb (and smart) users look for:
> First page would be:
> What do you want to install today ?
> - Update your system !!
> (Desktop side)
> - DVD/MPEG player (KDE, Gnome)
> - Music management software (KDE, Gnome)
> - Desktop eye-candy
> - Fonts
> - PDA conectivity and integration
> - OpenOffice: templates, clipart
> - Personal Finanse
> (Server side)
> - HA cluster management
> - Network monitoring tools
> - Web reporting tools
> - Complete enterprise mail solution
> - JBoss Application Server
> - Eclipse Rich Client Platform and IDE
> - GIF manipulation library
> - Chart generation stuff
> - MPEG manipulation stuff
> - HW drivers
> - Filesystem drivers
> - Java Virtual Machine and browser plugin
> Of course this should be all linked to TLDP howtos when possible.
> I think RPMForge should count number of user problems it can solve, and not
> the number of RPMs it contain.
I agree with your where it is practically (or technically) possible. The
seperation of the User/Developer/Packager tracks was constructed from the
idea that the expectations of these different players and the
communication with them is in essence very different.
And I agree that we should give new users an overview based on categories
(or domains) where a particular package belongs to instead of just/only
package names. The interface should also be very minimalistic in order not
to distract/confuse the user.
However the categories that an RPM package currently holds is very limited
for this and we may have to add our own categories (with a metatag) to
packages. So I welcome the idea and we should discuss this further (what
categories, what is practical, ...)
Also I don't see how we can count the number of user problems we can solve
(this is subjective and subject to change at any time) and I also fear
that linking to HOWTO documents is generally hard to implement (it is not
related to software packages per se and not every category has anything
useful, also tracking HOWTOs and validity is something we may want to
On the other hand if you can do it and maintain it, who am I to hold you
from doing it. But I think there are more important matters and we
should avoid implementing something that adds more work to the limited
resources. If you want to do it more than anything else, I'm not going to
stop you. :)
> I have more ideas about this draft, and I'm ready to share and contribute if
> people are interested.
> Of course behind it advanced users can still choose between stable and
> testing. But this is for advanced geeks that don't need 2 clicks actions or
> I like the way www.winfiles.com <http://www.winfiles.com> and
> windowsupdate.microsoft.com <http://windowsupdate.microsoft.com> work.
I can't use the latter as it requires windows apparently :) Nevertheless
we could take over a similar interface/structure. One of the
considerations is if we want to allow one package to belong to multiple
categories (since sometimes it is dubious)
PS I finished the freetype packages when my system was back (an IP change
apparently, most likely the end of the month IP change...), please verify.
I also added you as the authority, added a changelog item (since people
may be wondering what this package is doing there or what has changed) and
I added a VerbatimSource metatag so that in the future we can use this to
keep in sync.
You may also want to send the Source changes upstream (now they are a URL).
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
More information about the users