New Comps Groups

Christopher Stone chris.stone at gmail.com
Sun Nov 26 19:12:58 UTC 2006


On 11/26/06, Horst H. von Brand <vonbrand at inf.utfsm.cl> wrote:
> Wart <wart at kobold.org> wrote:
>
> [...]
>
> > If we're going to move to "<language> Development" groups for
> > language-specific development modules, then I'd also like to ask for a
> > "Tcl Development" group for the 18+ Tcl modules in FE.
>
> What about Ruby, C++, ...? Tk (yes, that one is usable from a variety of
> languages)? The various RDBMses? This will give a huge list of new groups.

There already exists a group for Ruby, C++ libraries would just go in
the generalized "Development Libraries" group, and I proposed
combining Tcl with Tk.  I'm not sure what you mean by the various
RDBMses, can you give an example?

>
> I'd vote for a system based on /functionality/ first, not implementation
> details like language. And I fail to see what good it could do to "Pull in
> all Perl related stuff", you probably need just a spattering of CPAN
> anyway.

The purpose of this is not to pull in every single Perl module.  The
main purpose is to make it easier for people to find packages.

I believe that if we use a system based on functionality we would end
up with a lot more groups and you end up with tons of packages that
cross over until multiple functionality groups.

We want people to be able to find packages easily.  So if you are a
developer using pirut, you already know what language you are using,
and you want to know what packages are available for your language. I
believe end-users want to know for example what PHP modules are
available to them, it is easy to find out this information when
grouped by language.

Ofcourse we do have some functionality groups such as "Web
Development", "GNOME Development" and you can easily place your
libraries or modules in multiple groups if you wish.

Please mention any functionality groups you think are missing, but
keep in mind it should be a group that has a lot of packages.  The
"Web Development" group currently has zero packages in it, so I
question its usefulness.




More information about the fedora-extras-list mailing list