Public SourceMage Discussion List

[Remko van der Vossen <wich AT yuugen.jp>]

On Tue, Apr 13, 2010 at 03:41:50AM -0400, Elisamuel Resto wrote:
> On 4/13/2010 3:26 AM, Remko van der Vossen wrote:
> > On Tue, Apr 13, 2010 at 12:16:14AM -0700, Eric Sandall wrote:
> >> On Sun, 11 Apr 2010 22:33:37 -0400
> >> Elisamuel Resto <ryuji AT simplysam.us> wrote:
> >>
> >>> On 4/11/2010 10:13 PM, Eric Sandall wrote:
> >>>> On Sun, 11 Apr 2010 19:59:23 -0300
> >>>> Ismael Luceno <ismael.luceno AT gmail.com> wrote:
> >>>>
> >>>>> libnet-perl == perl-libnet ??
> >>>>>
> >>>>> Shouldn't we have some kind of standard to avoid this?
> >>>>
> >>>> We generally follow how upstream calls the project (usually via
> >>>> their tarball name). That and developer's doing a quick `gaze
> >>>> search` should avoid most duplicates.
> >>>>
> >>>> -sandalle
> >>>
> >>> I would prefer, personally, that language-specific spells would either
> >>> be prefixed with their language or at the very least, on the section
> >>> for the language. For example, we have xcache, but php-xcache would
> >>> make more sense as to what it is related to. Same with xdebug and a
> >>> the memcache pecl extension. Though in php's case, those would be
> >>> either php- or pecl-/pear- depending on their source.
> >>>
> >>> Other distros follow prefixing perl stuff with perl-, which has saved
> >>> me trouble for searching packages for something I had forgotten.
> >>
> >> That would probably be a good policy to follow...but do you mean for
> >> all non-GCC languages or do you want to start prefixing c++- (or cpp),
> >> c-, f95-, etc.? What about mono- or c#- or c-sharp-?
> >>
> >> Perhaps only python/perl packages should have these prefixes? Ruby?
> > 
> > I would tend to disagree, why needlessly lengthen all the spell names?
> > Sticking to what upstream calls their package would be much more
> > convenient. We have sections and keywords to do grouping... If we need
> > better grouping we'd probably do better in developing keywords more.
> > 
> > Remko.
> 
> I would incline to agree, but given the example of pecl extensions for
> php, where they often name the extension the same as the upstream
> package. We can't have two spells with the same name now, can we? The
> obvious step would be to prefix it, and then you would have prefixed and
> non-prefixed spells, thus, creating a unorganized mess to my eyes.

I really don't think name clashes are that common, usually for stuff
like language bindings the packa name actually includes a reference to
the language, and yes, then it definately should be part of the spell
name as well, as the spell name should just be the package name. And if
there are clashes maybe we should rather poke the developers to name
their package more sensibly than create unwieldy naming schemes to
circumvent the problem.

And this doesn't prevent the problem of name clashes anyway, there'll
still be cases where entirely different packages will have the same
name. Granted it may be rarer but it's still going to happen.

> I agree with you for 80% of use-cases in these regards, but
> language-dependent spells (especially modules for said languages) would
> benefit from this when its time to look for spells easily.
> 
> Sure, I can look for a spell that depends on perl and check if its a
> module, but isn't it more convenient to just search for anything that
> begins with `perl-'?

In my eyes, no, it would be much easier to gaze section $whatever and/or
gaze keyword $whatever.

> In regards to keywords, I would love to see keywords used more, but
> there are tons of spells in the grimoire with generic keywords that fail
> to represent their contents specifically.

All the more reason to start fixing up the keywords and provide ways for
them to get used instead of kludging keywords into spell names.

Remko.