Proposal: Prefix language-name for language library packages

Proposal: Prefix language-name for language library packages

[Hartmut Goebel]

Hi,

I propose to generalizing the specification [1,2] as we already have for
Perl, Python and Java for most programming languages. In short:

Package names should be prefixed with the name of the language and if
the package name already contains the name of the language, it gets
removed there.

I quickly scanned the current package definitions and found:

guile: 2 package to change
haskell: ca. 2 package to be changed
julia: 0
d (lcd.xscm): 0
nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
lua: 0
m4: 0
ocaml: 1
ruby: 0
r (statistics.scm): 0
scheme: 1 or 2
smalltalk: 0
tcl: 0

Maybe we should extend this even to frameworks like node.js?

Comments are welcome.

[1] http://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n11005
[2] https://lists.gnu.org/archive/html/guix-devel/2016-04/threads.html#00551

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Proposal: Prefix language-name for language library packages

[Danny Milosavljevic]

Hi,

I've always like the Gentoo approach most. Have a qualified package name like

  dev-java/ant

and if you try to install "ant" and it's unique: good.
If you try to install "ant" and there are multiple ones: you get a disambiguation error.
If you try to install "dev-java/ant" there's no ambiguity.

I'm aware that it's not implemented that way in "guix package" right now, however it would be easy to use the Guile module system for that end.  

Things like this are always easy to add later as long nobody make the package name "java-ant" which would make the qualified name

  dev-java/java-ant

which isn't so nice.

That said, Guix is not Gentoo. 

Directory hierarchies have never had a problem doing such categorization. Special-casing "xx-xxx" to be a poor man's directory feels... wrong.

That said, many package managers do it the "xx-xxx" way (and many don't).

Compare the input dependencies of a package

  (define java-maven
    (package
       (inputs '(("java-jvm" ,java-jvm)
                 ("java-xyz" ,java-xzy)
                 ("java-abc" ,java-abc)))))

Very redundant, no?

This kind of disambiguation is exactly what the module system can do best - and Guile's module system even allows you to add a prefix to all names when importing a module, so you can have the best of both choices.

Re: Proposal: Prefix language-name for language library packages

[Leo Famulari]

On Sun, Apr 24, 2016 at 03:22:03PM +0200, Hartmut Goebel wrote:
> Hi,
> 
> I propose to generalizing the specification [1,2] as we already have for
> Perl, Python and Java for most programming languages. In short:
> 
> Package names should be prefixed with the name of the language and if
> the package name already contains the name of the language, it gets
> removed there.
> 
> I quickly scanned the current package definitions and found:
> 
> guile: 2 package to change
> haskell: ca. 2 package to be changed
> julia: 0
> d (lcd.xscm): 0
> nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
> lua: 0
> m4: 0
> ocaml: 1
> ruby: 0
> r (statistics.scm): 0
> scheme: 1 or 2
> smalltalk: 0
> tcl: 0

What about C? Do we need c-linux-libre? ;)

Re: Proposal: Prefix language-name for language library packages

[Hartmut Goebel]

Am 24.04.2016 um 20:57 schrieb Leo Famulari:
> What about C? Do we need c-linux-libre? ;)

Oh, you hit the weak point of this proposal: I can not formulate a rule,
why e.g. libsodium does not need to be prefixed by "c-". And what about
c++ libraries? Maybe the main difference is that one can not (or only
hardly) use some (let's say) ruby package in C, whereas the other way
round is not much of a problem.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Proposal: Prefix language-name for language library packages

[alírio eyng]

Hartmut Goebel:
>Am 24.04.2016 um 20:57 schrieb Leo Famulari:
>> What about C? Do we need c-linux-libre?
...
>why e.g. libsodium does not need to be prefixed by "c-"
the c bias is unix heritage.

c-linux-libre-headers is good to contrast with cl-hurd[0] or pyhurd[1]
similarly there are cryptography libraries for other languages[2]

i agree to prefix every package which only interface is for a specific
programming language.

[0]http://www.gnu.org/software/hurd/user/flaviocruz.html
[1]http://savannah.nongnu.org/projects/pyhurd/
[2]https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries#Cryptography_libraries_and_their_origin

Re: Proposal: Prefix language-name for language library packages

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Sun, Apr 24, 2016 at 03:22:03PM +0200, Hartmut Goebel wrote:
>> Hi,
>> 
>> I propose to generalizing the specification [1,2] as we already have for
>> Perl, Python and Java for most programming languages. In short:
>> 
>> Package names should be prefixed with the name of the language and if
>> the package name already contains the name of the language, it gets
>> removed there.
>> 
>> I quickly scanned the current package definitions and found:
>> 
>> guile: 2 package to change
>> haskell: ca. 2 package to be changed
>> julia: 0
>> d (lcd.xscm): 0
>> nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
>> lua: 0
>> m4: 0
>> ocaml: 1
>> ruby: 0
>> r (statistics.scm): 0
>> scheme: 1 or 2
>> smalltalk: 0
>> tcl: 0
>
> What about C? Do we need c-linux-libre? ;)

Furthermore, what about multiple-language packages?  I’m thinking of
‘c+guile-guile’ and ‘c+siod+python-gimp’.

;-)

Ludo’.

Re: Proposal: Prefix language-name for language library packages

[Ludovic Courtès]

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> I propose to generalizing the specification [1,2] as we already have for
> Perl, Python and Java for most programming languages. In short:
>
> Package names should be prefixed with the name of the language and if
> the package name already contains the name of the language, it gets
> removed there.
>
> I quickly scanned the current package definitions and found:
>
> guile: 2 package to change
> haskell: ca. 2 package to be changed
> julia: 0
> d (lcd.xscm): 0
> nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
> lua: 0
> m4: 0
> ocaml: 1
> ruby: 0
> r (statistics.scm): 0
> scheme: 1 or 2

What do you mean by “scheme”?  Scheme packages are usually not
interchangeable among Scheme implementations, so we’d have
guile != racket != MIT Scheme, etc.

> smalltalk: 0
> tcl: 0

I’m all for it, especially given that this is pretty much the status
quo.  :-)

So, patches welcome for the 5-or-so packages above.

A common exception to the rule is packages that offer a CLI/GUI that is
a common entry point to the package–e.g., Guix, Unison, patches, Pius,
Xmonad, Awesome.  IOW, the rule would apply to libraries only.

There may be other cases where it’d be useful to make exceptions.

Thoughts?

Ludo’.

Re: Proposal: Prefix language-name for language library packages

[Leo Famulari]

On Thu, Apr 28, 2016 at 01:56:15PM +0200, Ludovic Courtès wrote:
> Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:
> 
> > I propose to generalizing the specification [1,2] as we already have for
> > Perl, Python and Java for most programming languages. In short:
> >
> > Package names should be prefixed with the name of the language and if
> > the package name already contains the name of the language, it gets
> > removed there.
> >
> > I quickly scanned the current package definitions and found:
> >
> > guile: 2 package to change
> > haskell: ca. 2 package to be changed
> > julia: 0
> > d (lcd.xscm): 0
> > nqc (lego.scm): 0 --> prefix "lego-"? OTOH this is a commercial brand
> > lua: 0
> > m4: 0
> > ocaml: 1
> > ruby: 0
> > r (statistics.scm): 0
> > scheme: 1 or 2
> 
> What do you mean by “scheme”?  Scheme packages are usually not
> interchangeable among Scheme implementations, so we’d have
> guile != racket != MIT Scheme, etc.
> 
> > smalltalk: 0
> > tcl: 0
> 
> I’m all for it, especially given that this is pretty much the status
> quo.  :-)
> 
> So, patches welcome for the 5-or-so packages above.
> 
> A common exception to the rule is packages that offer a CLI/GUI that is
> a common entry point to the package–e.g., Guix, Unison, patches, Pius,
> Xmonad, Awesome.  IOW, the rule would apply to libraries only.

Yes, it makes sense for libraries that are "tied" to their language. Of
course:

> There may be other cases where it’d be useful to make exceptions.

Re: Proposal: Prefix language-name for language library packages

[alírio eyng]

Ludovic Courtès:
>what about multiple-language packages?  I’m thinking of
>‘c+guile-guile’ and ‘c+siod+python-gimp’.
the ideal categorization would be one output for each interface.
so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
"gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
"emacs -batch -eval").
e.g. guile:c and emacs:tui are pretty useless for me, so i could not
install them.
it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
and "emacs:no-gui" (tui+elisp), linux-libre, ...

c nomenclature:
packages with c interface currently have nothing, "lib" (prefix or
postfix), "c-", "-c", "4c" or "-headers".
e.g. "readline" "libunistring" "htslib" "c-ares" "json-c" "icu4c"
"mesa-headers" "linux-libre-headers".
and lots of synopses with nothing, "C library for", "C library
providing", "C library to", "implementation in C" or "written in C".

this would be consistent with trisquel:
"libreadline-dev" "libunistring-dev" "libhts-dev" "libc-ares-dev"
"libjson-c-dev" "libicu-dev" "libmesa-dev" (and "libmesa")
"linux-libre-image" (and "linux-libre-libc-dev" or
"linux-libre-headers").

suggestions:
be consistent with other languages:
"c-readline" "c-unistring" "c-hts" "c-ares" "c-json" "c-icu" "c-mesa"
(hide the runtime) "linux-libre" (and "linux-libre:c"; actually the
system would use "linux-libre-old:c" to keep current semantics).
remove this information from synopses (or standardize to all).

Re: Proposal: Prefix language-name for language library packages

[Leo Famulari]

On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
> Ludovic Courtès:
> >what about multiple-language packages?  I’m thinking of
> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
> the ideal categorization would be one output for each interface.
> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
> "emacs -batch -eval").
> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
> install them.
> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
> and "emacs:no-gui" (tui+elisp), linux-libre, ...

I don't think we should split packages up unless there is a pressing
reason to do it. For example, some our packages have a rarely-used
component that uses a lot of disk space or has a very large dependency.
It makes sense to put those in different outputs.

But if we go too far, nobody will be able to tell which package to
install to accomplish their task.

> c nomenclature:
> packages with c interface currently have nothing, "lib" (prefix or
> postfix), "c-", "-c", "4c" or "-headers".
> e.g. "readline" "libunistring" "htslib" "c-ares" "json-c" "icu4c"
> "mesa-headers" "linux-libre-headers".
> and lots of synopses with nothing, "C library for", "C library
> providing", "C library to", "implementation in C" or "written in C".

Again, unless some package's headers take up a large amount of disk
space, or have some other onerous cost, I don't see a reason to put them
in a separate output.

Re: Proposal: Prefix language-name for language library packages

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>> Ludovic Courtès:
>> >what about multiple-language packages?  I’m thinking of
>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>> the ideal categorization would be one output for each interface.
>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
>> "emacs -batch -eval").
>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
>> install them.
>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
>> and "emacs:no-gui" (tui+elisp), linux-libre, ...
>
> I don't think we should split packages up unless there is a pressing
> reason to do it. For example, some our packages have a rarely-used
> component that uses a lot of disk space or has a very large dependency.
> It makes sense to put those in different outputs.
>
> But if we go too far, nobody will be able to tell which package to
> install to accomplish their task.

I agree.  I’d like to only split up packages when the effort is
justified.

>> c nomenclature:
>> packages with c interface currently have nothing, "lib" (prefix or
>> postfix), "c-", "-c", "4c" or "-headers".
>> e.g. "readline" "libunistring" "htslib" "c-ares" "json-c" "icu4c"
>> "mesa-headers" "linux-libre-headers".
>> and lots of synopses with nothing, "C library for", "C library
>> providing", "C library to", "implementation in C" or "written in C".
>
> Again, unless some package's headers take up a large amount of disk
> space, or have some other onerous cost, I don't see a reason to put them
> in a separate output.

It also isn’t necessarily practical to do so.

~~ Ricardo

Re: Proposal: Prefix language-name for language library packages

[alírio eyng]

On 4/29/16, Leo Famulari <leo@famulari.name> wrote:
> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>> Ludovic Courtès:
>> >what about multiple-language packages?  I’m thinking of
>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>> the ideal categorization would be one output for each interface.
>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
>> "emacs -batch -eval").
>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
>> install them.
>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
>> and "emacs:no-gui" (tui+elisp), linux-libre, ...
>
> I don't think we should split packages up unless there is a pressing
> reason to do it. For example, some our packages have a rarely-used
> component that uses a lot of disk space or has a very large dependency.
> It makes sense to put those in different outputs.
>
> But if we go too far, nobody will be able to tell which package to
> install to accomplish their task.
defining "too far" is a problem, but ok.
in the end splitting things (in packages or outputs) is just an
optimization; with unlimited resources we could just install
everything (ignoring security, untracked dependencies, ...).
note the difference between "ideal categorization" to answer about
multiple-language packages and "suggestions" (that i want
implemented).

>> c nomenclature:
>> packages with c interface currently have nothing, "lib" (prefix or
>> postfix), "c-", "-c", "4c" or "-headers".
>> e.g. "readline" "libunistring" "htslib" "c-ares" "json-c" "icu4c"
>> "mesa-headers" "linux-libre-headers".
>> and lots of synopses with nothing, "C library for", "C library
>> providing", "C library to", "implementation in C" or "written in C".
>
> Again, unless some package's headers take up a large amount of disk
> space, or have some other onerous cost, I don't see a reason to put them
> in a separate output.
note the "currently"; mesa and linux-libre (and emacs) are _already_
split in packages, so a reason should exist.
linux-libre-headers seems to avoid rebuilds.
i guess in mesa the runtime has some onerous cost (probably disk space).
splitting in outputs would be cleaner, and probably more efficient on hydra.
but mesa and linux-libre are corner cases, which my suggestion was
comprehensive enough to handle.

the point is trisquel has a standardized way to express c interface in
names (lib*-dev), guix doesn't; there's lot of evidence it would be
useful (eleven non-standardized ways).

Re: Proposal: Prefix language-name for language library packages

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>>> Ludovic Courtès:
>>> >what about multiple-language packages?  I’m thinking of
>>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>>> the ideal categorization would be one output for each interface.
>>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
>>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
>>> "emacs -batch -eval").
>>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
>>> install them.
>>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
>>> and "emacs:no-gui" (tui+elisp), linux-libre, ...
>>
>> I don't think we should split packages up unless there is a pressing
>> reason to do it. For example, some our packages have a rarely-used
>> component that uses a lot of disk space or has a very large dependency.
>> It makes sense to put those in different outputs.
>>
>> But if we go too far, nobody will be able to tell which package to
>> install to accomplish their task.
>
> I agree.  I’d like to only split up packages when the effort is
> justified.

Agreed.

FWIW, until recently Nixpkgs didn’t use multiple outputs much (info
"(guix) Packages with Multiple Outputs").  Lately they merged a change
to use them very aggressively.  So for instance, GNU libidn, which takes
800 KiB in total, has no less than 5 outputs:

  https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/libidn/default.nix

I think this is going a bit too far.  :-)

I think the approach should be to profile packages with ‘guix size’ and
to act mostly on a case-by-case basis.

Ludo’.

Re: Proposal: Prefix language-name for language library packages

[ng0]

ludo@gnu.org (Ludovic Courtès) writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Leo Famulari <leo@famulari.name> writes:
>>
>>> On Fri, Apr 29, 2016 at 06:31:24PM +0000, alírio eyng wrote:
>>>> Ludovic Courtès:
>>>> >what about multiple-language packages?  I’m thinking of
>>>> >‘c+guile-guile’ and ‘c+siod+python-gimp’.
>>>> the ideal categorization would be one output for each interface.
>>>> so "guile" (scheme), "guile:c", "gimp" (gui), "gimp:c", "gimp:siod",
>>>> "gimp:python", "emacs" (gui), "emacs:tui", "emacs:elisp" (to run
>>>> "emacs -batch -eval").
>>>> e.g. guile:c and emacs:tui are pretty useless for me, so i could not
>>>> install them.
>>>> it's worth to focus on packages already split: "emacs" (gui+tui+elisp)
>>>> and "emacs:no-gui" (tui+elisp), linux-libre, ...
>>>
>>> I don't think we should split packages up unless there is a pressing
>>> reason to do it. For example, some our packages have a rarely-used
>>> component that uses a lot of disk space or has a very large dependency.
>>> It makes sense to put those in different outputs.
>>>
>>> But if we go too far, nobody will be able to tell which package to
>>> install to accomplish their task.
>>
>> I agree.  I’d like to only split up packages when the effort is
>> justified.
>
> Agreed.
>
> FWIW, until recently Nixpkgs didn’t use multiple outputs much (info
> "(guix) Packages with Multiple Outputs").  Lately they merged a change
> to use them very aggressively.  So for instance, GNU libidn, which takes
> 800 KiB in total, has no less than 5 outputs:
>
>   https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/libidn/default.nix
>
> I think this is going a bit too far.  :-)
>
> I think the approach should be to profile packages with ‘guix size’ and
> to act mostly on a case-by-case basis.
>
> Ludo’.
>

To add my thoughts on this:

I think multiple language packages could be nice, but they could
also make getting into packaging incredible harder. Currently it
is very accessible and modular.
It would also introduce labeling problems and discussions, does
someone see it's mainly this and that language? Do we then decide
on the order of $lang in $lang+$lang+$lang-$package or do we
waste our times with individual package discussions and
preferences and also when to split up or not?
If we decide on something, it should be covering all
possibilities and minimize discussions which might arise from
it.


If we decide on one thing now we don't have to stick to it for
all eternity, it can change later if we see it doesn't work out
anymore.


Gentoo used to have herds, project groups for certain big or
themed projects. In the last council meeting they decided that
herds are no longer needed and wanted by the community, so they
are splitting them up.

-- 
♥Ⓐ ng0

Re: Proposal: Prefix language-name for language library packages

[Leo Famulari]

On Mon, May 02, 2016 at 09:50:43AM +0200, Ludovic Courtès wrote:
> FWIW, until recently Nixpkgs didn’t use multiple outputs much (info
> "(guix) Packages with Multiple Outputs").  Lately they merged a change
> to use them very aggressively.  So for instance, GNU libidn, which takes
> 800 KiB in total, has no less than 5 outputs:
> 
>   https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/libidn/default.nix
> 
> I think this is going a bit too far.  :-)

I agree. The time spent by humans figuring out which output to use will
probably never be "earned back" by the bandwidth and disk savings in
that case.

> I think the approach should be to profile packages with ‘guix size’ and
> to act mostly on a case-by-case basis.

Case-by-case, as with most things!

Re: Proposal: Prefix language-name for language library packages

[alírio eyng]

i suggested renaming:
readline, libunistring, htslib, c-ares, json-c, icu4c, ...
to:
c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...

no replies, is that implicit agreement?

Re: Proposal: Prefix language-name for language library packages

[Ricardo Wurmus]

alírio eyng <alirioeyng@gmail.com> writes:

> i suggested renaming:
> readline, libunistring, htslib, c-ares, json-c, icu4c, ...
> to:
> c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...
>
> no replies, is that implicit agreement?

I strongly disagree with this as it makes things needlessly confusing,
in my opinion.

It was fine to discuss this for Java as we only had a handful of Java
packages, but I don’t think it’s reasonable to do this for C and C++
stuff at all.

~~ Ricardo

Re: Proposal: Prefix language-name for language library packages

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> alírio eyng <alirioeyng@gmail.com> writes:
>
>> i suggested renaming:
>> readline, libunistring, htslib, c-ares, json-c, icu4c, ...
>> to:
>> c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...
>>
>> no replies, is that implicit agreement?
>
> I strongly disagree with this as it makes things needlessly confusing,
> in my opinion.

+1

We joked about adding this “c-” prefix earlier in this discussion, but
that’s really just a joke.

Thanks,
Ludo’.

Re: Proposal: Prefix language-name for language library packages

[Andreas Enge]

On Fri, May 06, 2016 at 02:45:48AM +0000, alírio eyng wrote:
> i suggested renaming:
> readline, libunistring, htslib, c-ares, json-c, icu4c, ...
> to:
> c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...
> no replies, is that implicit agreement?

I did not follow the discussion in all its details, but thought this part
was an obvious joke to illustrate the limits of the suggestion...
C being the natural GNU language and C++ its extension, I see no reason
to emphasise that a package is written in C.

Part of why we added a language prefix (for perl, I think, or maybe python
came first?) was also that the libraries had rather generic names. There
is perl-error, perl-html-form, perl-json and so on (not to speak of
perl-xyz containing bindings to some C library called xyz); we feared there
would be many collisions with existing C libraries and tools or further
interpreted languages.

Andreas

Re: Proposal: Prefix language-name for language library packages

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]

On Fri, May 06, 2016 at 10:12:14PM +0200, Andreas Enge wrote:
     On Fri, May 06, 2016 at 02:45:48AM +0000, al?rio eyng wrote:
     > i suggested renaming:
     > readline, libunistring, htslib, c-ares, json-c, icu4c, ...
     > to:
     > c-readline, c-unistring, c-hts, c-ares, c-json, c-icu, ...
     > no replies, is that implicit agreement?
     
     I did not follow the discussion in all its details, but thought this part
     was an obvious joke to illustrate the limits of the suggestion...
     C being the natural GNU language and C++ its extension, I see no reason
     to emphasise that a package is written in C.
     
     Part of why we added a language prefix (for perl, I think, or maybe python
     came first?) was also that the libraries had rather generic names. There
     is perl-error, perl-html-form, perl-json and so on (not to speak of
     perl-xyz containing bindings to some C library called xyz); we feared there
     would be many collisions with existing C libraries and tools or further
     interpreted languages.
     
     
Some packages already have rediculously long names.  I don't see a need to make them 
longer.  In fact, I would like to make some of them shorter.  For example:

perl-moosex-emulate-class-accessor-fast 
perl-catalyst-plugin-authorization-roles
perl-catalyst-traitfor-request-proxybase
perl-moosex-types-datetime-morecoercions
perl-catalyst-plugin-session-state-cookie
perl-plack-middleware-removeredundantbody 
perl-catalyst-component-instancepercontext
perl-catalyst-plugin-session-store-fastmmap
perl-catalyst-authentication-store-dbix-class
perl-plack-middleware-fixmissingbodyinredirect


J'

-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]