On Thu, Nov 18, 2004 at 04:32:12AM +0900, David A. Black wrote:
> > > I'm suddenly running kde3, xchat2,
> > > apache2, libxml2, etc.  Those are silly names for programs, whereas
> > > the original names were relatively reasonable.  
> > 
> > I personally don't find them silly; de gustibus non disputandum est.
> 
> Would you name a project "myproject3" on its first release? :-)

To which of the above would this apply? AFAIK none.
 
In libraries, the number serves a precise purpose; it makes less sense
in applications.

> > It makes sense to follow that convention for libraries, and there are
> > good reasons to do so...
> > 
> > > The prospect of everything having to end in a number as a packaging
> > > workaround suggests to me that something needs to be addressed in the
> > > packaging system. 
> > 
> > Are you going to contact developers from FreeBSD, Debian, Fedora, Suse,
> > PLD, Gentoo, etc to make them change their systems?
> 
> No; as I said, I'm hoping that this won't become customary in *Ruby*
> projects, 

I'm not sure I got the point across: they are all packaging Ruby software,
and if you're going to make their task harder, hence hindering the
diffusion of Ruby software and Ruby itself, you need a better reason
than aesthetics. I'm sure we both want to promote the usage of Ruby and
remove the obstacles that would keep people away from it.

Before rejecting the libfooN practice based on aesthetic arguments,
we would have to see if there's a reason for many (most?) repackagers
doing that. The experience from FreeBSD and Debian alone (due to their
sheer size) exceeds the rather limited packaging we've had in the Ruby
world so far. Even RPA's current ~150 ports are very far from FreeBSD's
10000.

> and was hoping that an archive like RPA wouldn't cultivate
> it.  But it doesn't sound like my hope has much hope :-) 

This hasn't been decided yet. But it is a likely choice, to the extent
that it would make RPA ports easier to adapt to several of the systems
mentioned above, and therefore easier to deploy. 

> > Since the new RubyMail will have a completely incompatible API, it is
> > de facto another library -- and no longer the original "RubyMail", hence
> > the possible need for another name. RubyMail2 shows its heritage.
> 
> It's one of many possible ways of conveying that information.  I like
> the more modular approach: project name, version number (including API
> version).  

Adding the soname to the library name doesn't preclude using version
numbers. They serve slightly different purposes.

-- 
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/