Subject: [alpine-devel] [RFC] package name policy change

From: Natanael Copa <[email-masked]>
Date: Wed, 6 Jul 2011 20:42:25 +0200

Hi,

I would like to propose a new package naming policy that simply forbids
use the characters that needs to be url encoded to be used in an url.

The reason is simply that those chars makes web services from scripts
slightly more complicated. We already had an issue[1] with this.

For example:

pkgname=gtk+2.0
wget http://example.com/someservice?pkgname=$pkgname

Does anyone have anything against this change?

Other comments?

[1] http://bugs.alpinelinux.org/issues/693

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Nathan Angelacos <[email-masked]>
Date: Wed, 06 Jul 2011 11:52:13 -0700

> use the characters that needs to be url encoded to be used in an url.

+1  (or how ever many votes I can cast.)

its a great simplification in a number of areas.

---

---

From: Paul Onyschuk <[email-masked]>
Date: Wed, 6 Jul 2011 22:34:13 +0200

On Wed, 6 Jul 2011 20:42:25 +0200

> Other comments?

What naming for those packages you suggest?  For C++ related things
using "pp" is pretty obvious (e.g. libgc++ -> libgcpp).  And simple "+"
should be changed to plus (e.g. gtk+ -> gtkplus)?

+1 (my vote probably doesn't count anyway, I'm just sharing my opinion).
Packages with wird naming aren't popular, so it should be easy to fix
and maintain. 

-- 
Paul Onyschuk <[email-masked]>

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 7 Jul 2011 08:21:00 +0200

On Wed, 6 Jul 2011 22:34:13 +0200
Paul Onyschuk <[email-masked]> wrote:

> using "pp" is pretty obvious (e.g. libgc++ -> libgcpp).  And simple
> "+" should be changed to plus (e.g. gtk+ -> gtkplus)?

What does in mean in practice. Good point.

I'm looking to what others do. Seems like debian/ubuntu allows + in the
name. Fedora too (so i assume all rpm based allows it).

The approx list is (-dev and -doc excluded):

libgc++
g++
libstdc++
gtk+
gtk+2.0
gtk+3.0
imagemagick-c++
libsigc++
tolua++
uclibc++

renaming g++ -> gpp will not work since there are another gpp
(http://en.nothingisreal.com/wiki/GPP)

libstdcpp is just ugly libstdcplusplus too.

gtk+ -> gtk works
gtk+2.0 -> gtk2 works
gtk+3.0 -> gtk3 works
imagemagick-c++ -> imagemagic-cpp might work
libsigcpp -> libsigcpp is ugly libsigcplusplus too.
tolua++ -> toluapp wont work. toluaplusplus is even worse.
uclibc++ can be removed.

hum... maybe it was not a good idea after all?
 
> +1 (my vote probably doesn't count anyway, I'm just sharing my
> opinion). Packages with wird naming aren't popular, so it should be
> easy to fix and maintain. 

Things like libstdc++ and imagemagick-c++ makes more sense than the
alternatives somehow.

Unless someone comes up with some good alternative to the above list I
think we'll just keep it as it is and will have to urlencode when
needed.

How about we allow + and disallow the others?

The will something like this work:
encoded_url=${url//+/%2B}

-nc

---