[ANN] rpa-base 0.2.3

Discussion in 'Ruby' started by Mauricio Fernández, Nov 15, 2004.

  1. rpa-base 0.2.3 is now available at http://rpa-base.rubyforge.org .

    Many of the most popular libraries/applications as per Rubyforge
    statistics (rake, redcloth, activerecord, rails, sqlite, log4r, ruvi,
    and some >140 more libs/apps) have been packaged for use with rpa-base
    0.2.3.

    Screenshots and animations showing rpa-base's operations can be found at
    http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_Base_In_Action .


    Foreword
    ========

    The Ruby Production Archive (RPA) will provide packages of Ruby
    libraries and programs in a form that allows production use, engineered
    through a stringent process resembling FreeBSD's or Debian's.

    rpa-base is a port/package manager designed to support RPA.
    Its scope and purposes are different to those of other systems like
    RubyGems.

    Please join #RPA on irc.freenode.net for additional information on
    RPA/rpa-base and their goals (several RPA developers and users hang
    around there). The FAQ list at
    http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_FAQ
    might prove useful too.


    Changes since 0.2.2
    ===============================

    This is mostly a bugfix release. Work on new features and a better UI is
    taking place in the 0.3 branch at the moment.

    * critical workaround for a modification in ostruct.rb introduced
    recently in Ruby's ruby_1_8 CVS branch and HEAD (1.9), which broke
    rpa-base altogether. Note that this workaround was released as a
    self-update, but people using recent 1.8 builds (including the latest
    preview) would not be able to install rpa-base for the first time

    * support for
    rpa install package1.rpa .... packageN.rpa
    (you can copy the binary packages built on one machine to another and
    install without a connection to the Internet)

    * rpa update doesn't limit the new/updated info to the last 14 days

    * bash completion script included (thanks to Brian Schröder, Nobu Nakada)

    * several minor bugfixes


    Status
    ======

    Please keep in mind that RPA is at an embryonic stage; this means that
    it is impossible to commit to all the long term goals stated in the
    manifesto (http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto) at
    the moment. This doesn't make rpa-base any less usable however.

    rpa-base requires Ruby 1.8.[12] (certainly 1.8 at least, it might work
    on 1.8.0); it has been tested on several Linux distributions (Debian,
    Fedora, older RH, Gentoo, etc), FreeBSD, DragonFly BSD, Mac OSX, win32
    (cygwin, 'pragmatic installer', WinXP and 2K).

    rpa-base is fairly stable at this stage; it has been tested on several
    platforms during the last 6 months. Since rpa-base can self-update,
    eventual bugs discovered through the intensive testing associated with
    a public release could be solved easily by upgrading rpa-base using
    rpa-base itself.

    We would appreciate any feedback on rpa-base.
    A mailing list has been set up for that purpose:
    http://rubyforge.org/mailman/listinfo/rpa-base-testers


    Features
    ========

    rpa-base is a port/package manager designed to support RPA's client-side
    package management. You can think of it as RPA's apt-get + dpkg. It
    features the following as of 0.2.3:

    * strong dependency management: rpa-base installs dependencies as needed,
    keeps track of reverse dependencies on uninstall, and will remove no
    longer needed dependencies

    * atomic (de)installs: operations on the local RPA installation are atomic
    transactions; the system has been designed to survive ruby crashes (OS
    crashes too on POSIX systems)

    * parallel installs: you can install several ports in parallel; building
    will be parallelized and the final phase will be serialized properly

    * self-hosting: rpa-base installs and updates itself

    * modular, extensible design: the 2-phase install is similar to FreeBSD and
    Debian's package creation; rpa-base packages need not be restricted
    to installing everything under a single directory ("1 package, 1 dir"
    paradigm)

    * rdoc integration: RDoc documentation for libraries is generated at install
    time (currently disabled on win32)

    * ri integration: ri data files are generated for all the libraries managed
    by RPA; you can access this information with ri-rpa

    * handling C extensions: if you have the required C toolchain, rpa-base can
    compile extensions as needed

    * unit testing: when a library is installed, its unit tests are run; the
    installation is canceled if they don't pass



    Several of the above features are illustrated in the screenshots and
    animations available at
    http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_Base_In_Action


    Limitations
    ===========

    A number of features have been pushed back to 0.3.0:
    * full support for binary platform-specific packages
    * signed packages/ports
    * system-wide configuration system
    * better UI

    In practice, the first one is the most limiting at the moment since it means
    that win32 users in particular need a working C toolchain to install
    extensions. This will soon be addressed.


    RPA needs your help
    ===================
    RPA is an ambitious project in need for developers. These are some of the
    areas that need to be worked on:
    * packaging (new software and package maintenance)
    * setting up a permanent repository infrastructure
    * cross-compilation and build automation
    * website development (should provide package indexes, QA section,
    bugtracking, etc)

    Please contact us through RubyForge's ML at
    http://rubyforge.org/mailman/listinfo/rpa-base-testers
    or drop me an email at <> (adding RPA to the subject
    will help get it past the spam filtering ;) or via IRC, #RPA on
    freenode.net if you have any interest or for any additional information
    on RPA/rpa-base and their goals.

    --
    Hassle-free packages for Ruby?
    RPA is available from http://www.rubyarchive.org/
     
    Mauricio Fernández, Nov 15, 2004
    #1
    1. Advertising

  2. Mauricio Fernández <> writes:

    > rpa-base 0.2.3 is now available at http://rpa-base.rubyforge.org .


    Hi Mauricio,

    I just noticed that RubyMail is part of RPA -- pretty neat! :)

    I am planning to release a new major version of RubyMail that is
    completely incompatible with prior versions. While the package name
    will still be RubyMail, the libs will be in 'rubymail/*' instead of
    'rmail/*'. I have noticed that the library path location 'rmail' has
    caused packages to call their packages 'rmail', makes it hard for me
    to actually identify them as being RubyMail.

    One advantage of this is that both old and new versions of rubymail
    will be able to co-exist.

    Will this totally screw RPA?

    --
    matt
     
    Matt Armstrong, Nov 16, 2004
    #2
    1. Advertising

  3. On Tue, Nov 16, 2004 at 02:08:23PM +0900, Matt Armstrong wrote:
    > > rpa-base 0.2.3 is now available at http://rpa-base.rubyforge.org .

    >
    > I just noticed that RubyMail is part of RPA -- pretty neat! :)


    Would you like to receive notifications of future package revisions?

    > I am planning to release a new major version of RubyMail that is
    > completely incompatible with prior versions. While the package name
    > will still be RubyMail, the libs will be in 'rubymail/*' instead of
    > 'rmail/*'. I have noticed that the library path location 'rmail' has
    > caused packages to call their packages 'rmail', makes it hard for me
    > to actually identify them as being RubyMail.


    mmm yes, I can see librmail-ruby1.{6,8} in Debian...

    > One advantage of this is that both old and new versions of rubymail
    > will be able to co-exist.
    >
    > Will this totally screw RPA?


    I hope not :)

    Since your new major version is going to be completely incompatible with
    the previous ones, I think it would make sense to do the equivalent to a
    soname change, that is, something like
    require 'rubymail' ==> require 'rubymail1'
    The port/package name would be rubymail1; in time, the current rubymail
    port/package, corresponding to 0.17, could be renamed to rubymail0.

    The major number (of the API) actually belongs to the name of the
    library, in a way, and the 'soname change' is less invasive than a
    versioned require, and nicer to third party port/package systems (think
    of Debian for instance).

    --
    Hassle-free packages for Ruby?
    RPA is available from http://www.rubyarchive.org/
     
    Mauricio Fernández, Nov 17, 2004
    #3
  4. Hi --

    On Wed, 17 Nov 2004, Mauricio Fernández wrote:

    > On Tue, Nov 16, 2004 at 02:08:23PM +0900, Matt Armstrong wrote:
    > > > rpa-base 0.2.3 is now available at http://rpa-base.rubyforge.org .

    > >
    > > I just noticed that RubyMail is part of RPA -- pretty neat! :)

    >
    > Would you like to receive notifications of future package revisions?
    >
    > > I am planning to release a new major version of RubyMail that is
    > > completely incompatible with prior versions. While the package name
    > > will still be RubyMail, the libs will be in 'rubymail/*' instead of
    > > 'rmail/*'. I have noticed that the library path location 'rmail' has
    > > caused packages to call their packages 'rmail', makes it hard for me
    > > to actually identify them as being RubyMail.

    >
    > mmm yes, I can see librmail-ruby1.{6,8} in Debian...
    >
    > > One advantage of this is that both old and new versions of rubymail
    > > will be able to co-exist.
    > >
    > > Will this totally screw RPA?

    >
    > I hope not :)
    >
    > Since your new major version is going to be completely incompatible with
    > the previous ones, I think it would make sense to do the equivalent to a
    > soname change, that is, something like
    > require 'rubymail' ==> require 'rubymail1'
    > The port/package name would be rubymail1; in time, the current rubymail
    > port/package, corresponding to 0.17, could be renamed to rubymail0.
    >
    > The major number (of the API) actually belongs to the name of the
    > library, in a way, and the 'soname change' is less invasive than a


    I wouldn't say it does unless someone decides they want to release a
    library called "mylib7" or whatever. The name of the library is the
    name of the library.

    > versioned require, and nicer to third party port/package systems (think
    > of Debian for instance).


    Can I put in a plea for not cultivating the "program2" syndrome in
    Ruby programs and libraries? Maybe it's just a pet peeve... but I
    really hate it when, a year or two after setting up a system with kde,
    xchat, apache, libxml, etc., I'm suddenly running kde3, xchat2,
    apache2, libxml2, etc. Those are silly names for programs, whereas
    the original names were relatively reasonable.

    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. Surely having a package/program/library name and a
    version number as separate things is not only more aesthetically
    appealing but vastly more scaleable.


    David (who intends to keep calling Ruby Ruby, whatever its version :)

    --
    David A. Black
     
    David A. Black, Nov 17, 2004
    #4
  5. On Wed, Nov 17, 2004 at 11:58:35PM +0900, David A. Black wrote:
    > > versioned require, and nicer to third party port/package systems (think
    > > of Debian for instance).

    >
    > Can I put in a plea for not cultivating the "program2" syndrome in
    > Ruby programs and libraries? Maybe it's just a pet peeve... but I
    > really hate it when, a year or two after setting up a system with kde,
    > xchat, apache, libxml, etc., 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.
    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?

    > Surely having a package/program/library name and a
    > version number as separate things is not only more aesthetically

    ==============
    It's not primarily about the version number itself but about an API
    declaration.

    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.

    > appealing but vastly more scaleable.
    >
    >
    > David (who intends to keep calling Ruby Ruby, whatever its version :)


    Unless when referring to Ruby 2 I guess...

    --
    Hassle-free packages for Ruby?
    RPA is available from http://www.rubyarchive.org/
     
    Mauricio Fernández, Nov 17, 2004
    #5
  6. Mauricio Fernández

    Aredridel Guest

    > Can I put in a plea for not cultivating the "program2" syndrome in
    > Ruby programs and libraries? Maybe it's just a pet peeve... but I
    > really hate it when, a year or two after setting up a system with kde,
    > xchat, apache, libxml, etc., I'm suddenly running kde3, xchat2,
    > apache2, libxml2, etc. Those are silly names for programs, whereas
    > the original names were relatively reasonable.


    I agree that it's among the most ugly things ever, having to mix up
    the name with the number.

    The biggest problem comes from the fact that selecting a library
    essentially needs a primary key of (name, version); the filesystem
    doesn't have separate fields, so every language or system solves the
    versioning selection problem differently.

    There's the contextual selector (gems), where you supply metadata and
    it picks the right one. Heaven help you if you need both.

    There's the explicit versioning model, like libxml2, which ugly, never
    has name-space collisions, at the expense of having to apply the
    version number by hand. It's a very IETF-style solution: guaranteed to
    work as long as everyone follows best practice, and lets you blame the
    ones that don't. Ugly, too, just like a lot of IETF protocols.

    Then there's the head-in-the-sand method, where you ignore it and hope
    you never have conflicts. It only works for small projects.

    And then there's the Raymond Chen Microsoft camp, where you just bend
    yourself into pieces to not break anything. Who cares if the project
    is ten times more complex? At least it won't break the old usage.

    > 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. Surely having a package/program/library name and a
    > version number as separate things is not only more aesthetically
    > appealing but vastly more scaleable.


    Handling it in the packaging system at some point moves it back to the
    filesystem, at huge code complexity expense. If you "require_versioned
    'foo', 2", then at some point, there has to be code that turns that
    into /rubylibdir/foo-2 or something similar to load the files? Why not
    skip that and save a few characters and just have "require foo2"?

    I happen to think that "foo2" looks really ugly, because people run it
    together and can't tell what's the family name and what's the specific
    instance version, and developers start munging it and your mailing
    list starts looking like "install foo" "which foo?" "2.0" "Oh, you
    mean foo2! I thought that was something else." My simple suggestion
    to fix that is to put a dash in the name. "require 'foo-2'" neither
    offends my sensibilities, nor does it require any maintenance by
    anyone other than the package author.

    If the internal namespaces follow similar conventions, you even have
    the problem of diamond dependencies solved:

    app requires framework which needs lib version 1; app requires
    framework which needs lib version 2.

    It's not common (yet, thankfully), but if everyone puts the major API
    version in the library name and namespace modules, then it's a non
    problem. It's ugly, but it will never break. If there's no namespace
    management, then ugly collisions occur, and you get answers like "No,
    you can't use foo with bar, because they need different versions of
    baz"

    > David (who intends to keep calling Ruby Ruby, whatever its version :)


    Ari, who intends to do the same, but be specific when it matters.

    P.S. I hated libfoo2, as well. .. until I had to fix something that
    was busted because of versioning issues. Now I can't reccomend it
    strongly enough.
     
    Aredridel, Nov 17, 2004
    #6
  7. Hi --

    On Thu, 18 Nov 2004, Mauricio Fernández wrote:

    > On Wed, Nov 17, 2004 at 11:58:35PM +0900, David A. Black wrote:
    > > > versioned require, and nicer to third party port/package systems (think
    > > > of Debian for instance).

    > >
    > > Can I put in a plea for not cultivating the "program2" syndrome in
    > > Ruby programs and libraries? Maybe it's just a pet peeve... but I
    > > really hate it when, a year or two after setting up a system with kde,
    > > xchat, apache, libxml, etc., 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? :)

    > 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, and was hoping that an archive like RPA wouldn't cultivate
    it. But it doesn't sound like my hope has much hope :)

    > > Surely having a package/program/library name and a
    > > version number as separate things is not only more aesthetically

    > ==============
    > It's not primarily about the version number itself but about an API
    > declaration.
    >
    > 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).

    > > appealing but vastly more scaleable.
    > >
    > >
    > > David (who intends to keep calling Ruby Ruby, whatever its version :)

    >
    > Unless when referring to Ruby 2 I guess...


    Yes, Ruby 2, when specifically referring to something unique to Ruby
    2, but not Ruby2 as the name of the language :)


    David

    --
    David A. Black
     
    David A. Black, Nov 17, 2004
    #7
  8. Mauricio Fernández

    Ryan Davis Guest

    On Nov 17, 2004, at 8:47 AM, Mauricio Fernández wrote:

    >> Surely having a package/program/library name and a
    >> version number as separate things is not only more aesthetically

    > ==============
    > It's not primarily about the version number itself but about an API
    > declaration.
    >
    > 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.


    I disagree completely. Every time I extend a class or change the
    semantics of a method I'm making an "incompatible API". That is just
    part of writing code. I'm not going to change the package name every
    time I make an incompatible release. I'd be up to ZenWeb211 and
    RubyInline39 by now. Despite all those incompatible releases, I haven't
    gotten any complaints about my package names being misleading.

    Further, I put VERSION in all of my main modules / classes in order to
    allow testing against to determine levels of compatibility.

    The only reason I see really needing to change the package name is if
    you wanted to have multiple versions installed at the same time and
    usable potentially by the same morass of dependencies. Having 3
    separate versions of libtool, 2 of autoconf, and 2 of automake on my
    freebsd boxen is more than frustrating. I'd rather not have that spread
    into ruby.

    >> David (who intends to keep calling Ruby Ruby, whatever its version :)

    >
    > Unless when referring to Ruby 2 I guess...


    Your quips (sprinkled throughout the entire email) not do not help your
    position and are not appreciated.
     
    Ryan Davis, Nov 17, 2004
    #8
  9. Mauricio Fernández

    Aredridel Guest

    > > 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.

    >
    > I disagree completely. Every time I extend a class or change the
    > semantics of a method I'm making an "incompatible API". That is just
    > part of writing code. I'm not going to change the package name every
    > time I make an incompatible release. I'd be up to ZenWeb211 and
    > RubyInline39 by now. Despite all those incompatible releases, I haven't
    > gotten any complaints about my package names being misleading.


    You're in a relatively unique situation among framework authors:
    things that depend on your framework are really rare. Frameworks like
    ZenWeb lie halfway between applications, with nothing that depend on
    them, and things like RubyMail or TMail, where many, many things
    depend on their APIs being stable.

    Do be careful when releasing incompatible APIs -- if someone depends
    on the old semantics, they'll be bitten, of course, when it changes.
    For some things, a little thrash is okay, but in a relatively mature
    library, the thrash can set off a whole chain reaction of everyone
    having to add some hack to make their library work with multiple
    versions of yours, or detecting when which version is loaded, and
    adjusting accordingly. Then packagers who tighten up dependencies and
    make sure things all work together have to go debug that code and make
    sure it doesn't get in the way.

    > Further, I put VERSION in all of my main modules / classes in order to
    > allow testing against to determine levels of compatibility.


    Good! That helps keep the effects from rippling out so far.

    > The only reason I see really needing to change the package name is if
    > you wanted to have multiple versions installed at the same time and
    > usable potentially by the same morass of dependencies. Having 3
    > separate versions of libtool, 2 of autoconf, and 2 of automake on my
    > freebsd boxen is more than frustrating. I'd rather not have that spread
    > into ruby.


    If libtool, autoconf and automake put version numbers in, so that
    autoconf 1 was autoconf-1, autconf 2.13 was autoconf-2 and autoconf
    2.57 was autoconf-3, it wouldn't be much of a problem. One would grump
    about "that's silly, a number in the name, oh well". And it would
    never break. As it is, dealing with multiples of those three packages
    drives me nuts when working on PLD.

    Spreading it unneccesarily is really bad. There's times, though, when
    it's time to say "enough with this cruft, time for an incompatible
    rewrite". That's when you bump the version -- or, if you're the zany,
    _why-like type, you change the name from StarMonkey to CunningFox.
    Either way works, though the full name change is a bit harder to
    follow unless you mention "CunningFox, the successor to StarMonkey"
    everywhere (not that that's bad).

    There's a point in every library's life, I think, where people start
    looking on it as stable; at that point, it's really nice to appease
    those who aren't among the early adopters, so that one can say "X api
    won't change in this branch". That's when the soname-style versioning
    is really nice. It doesn't happen to every library.

    soname-style versioning is appropriate for libraries like TMail,
    RMail, racc, and for anything in the standard library. Any
    incompatible change in these, especially if at all large, is going to
    break a lot of things that depend on it. DBI's another in this
    category.

    ZenWeb isn't there yet. It's still used by the early-adopter sorts,
    who'd spend an hour or two porting scripts to a new version, where
    it's not going to break something in heavy production, or if it would,
    there's a staff there to manage the update.

    Then there's things like syck, where an API change would break a ton,
    but there's no real reason to break the API. It's a perfect candidate
    for the Raymond Chen approach: don't change it if it'll break
    anything. Additions to the API only.

    Ari
     
    Aredridel, Nov 17, 2004
    #9
  10. On Thu, Nov 18, 2004 at 05:29:46AM +0900, Ryan Davis wrote:
    > >>Surely having a package/program/library name and a
    > >>version number as separate things is not only more aesthetically

    > > ==============
    > >It's not primarily about the version number itself but about an API
    > >declaration.
    > >
    > >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.

    >
    > I disagree completely. Every time I extend a class or change the
    > semantics of a method I'm making an "incompatible API".


    Well maybe I'm drawing too many conclusions from the "*completely*
    incompatible" expression (emphasis mine). I assumed it meant a radical
    change, which makes the lib. so different that it could use a new name.
    We would have to see the code or ask Matt Armstrong about the extent of
    the changes.

    > That is just part of writing code. I'm not going to change the package name every
    > time I make an incompatible release. I'd be up to ZenWeb211 and
    > RubyInline39 by now. Despite all those incompatible releases, I haven't
    > gotten any complaints about my package names being misleading.


    Note that I am not advocating for a library name change on every
    incompatible release; that's something the usual x.y.z versioning scheme
    aka "rational versioning policy" handles well:

    http://rubygems.rubyforge.org/wiki/wiki.pl?RationalVersioningPolicy

    That's a fairly exceptional measure taken in some precise situations;
    RubyMail's case looked like one of them but we cannot be sure until Matt
    clarifies that.

    > Further, I put VERSION in all of my main modules / classes in order to
    > allow testing against to determine levels of compatibility.


    That seems a good idea; it should probably belong into
    http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices or
    http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign

    > The only reason I see really needing to change the package name is if
    > you wanted to have multiple versions installed at the same time and
    > usable potentially by the same morass of dependencies.


    Matt Armstrong talked about making RubyMail and the "new RubyMail"
    (which I would consider packaging as rubymail1) coexist. By doing
    the 'soname renaming', you make that easier for a number of systems,
    and third party sw. dependent on RubyMail wouldn't need to be adapted
    specifically for them.

    --
    Hassle-free packages for Ruby?
    RPA is available from http://www.rubyarchive.org/
     
    Mauricio Fernández, Nov 17, 2004
    #10
  11. On Thu, Nov 18, 2004 at 04:32:12AM +0900, David A. Black wrote:
    > > 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. We all want to promote the usage of Ruby and remove the
    obstacles that would keep people away from it: making Ruby software easy
    to deploy is one of RPA's goals, and the RubyGems team is committed to
    making RubyGems packages easy to repackage for other systems.

    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 one 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 could be a sensible 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/
     
    Mauricio Fernández, Nov 17, 2004
    #11
  12. Mauricio Fernández <> writes:

    > On Tue, Nov 16, 2004 at 02:08:23PM +0900, Matt Armstrong wrote:
    >>
    >> > rpa-base 0.2.3 is now available at http://rpa-base.rubyforge.org
    >> > .

    >>
    >> I just noticed that RubyMail is part of RPA -- pretty neat! :)

    >
    > Would you like to receive notifications of future package revisions?


    Sure, but only if it means zero effort on your part. Otherwise I can
    periodically poll RPA as I'm interested.


    > Since your new major version is going to be completely incompatible
    > with the previous ones, I think it would make sense to do the
    > equivalent to a soname change, that is, something like
    >
    > require 'rubymail' ==> require 'rubymail1'


    That's exactly it.

    require 'rmail' ==> require 'rubymail'
    RMail::Message ==> RubyMail::Message

    This rename is somewhat random, but rectifies something I think I got
    wrong from the start (not matching the package name with the package's
    module name space). It also marks the beginning of what I plan to be
    another active and comparably unstable phase of RubyMail development,
    so it makes some sense to do this now.

    --
    matt
     
    Matt Armstrong, Nov 18, 2004
    #12
  13. Mauricio Fernández

    Aredridel Guest

    > > require 'rubymail' ==> require 'rubymail1'
    >
    > That's exactly it.
    >
    > require 'rmail' ==> require 'rubymail'
    > RMail::Message ==> RubyMail::Message
    >
    > This rename is somewhat random, but rectifies something I think I got
    > wrong from the start (not matching the package name with the package's
    > module name space). It also marks the beginning of what I plan to be
    > another active and comparably unstable phase of RubyMail development,
    > so it makes some sense to do this now.


    Perfect! No namespace conflict. It'll be a breeze to piecemeal port.
     
    Aredridel, Nov 18, 2004
    #13
  14. On Thu, Nov 18, 2004 at 02:55:29PM +0900, Matt Armstrong wrote:
    > > Since your new major version is going to be completely incompatible
    > > with the previous ones, I think it would make sense to do the
    > > equivalent to a soname change, that is, something like
    > >
    > > require 'rubymail' ==> require 'rubymail1'

    >
    > That's exactly it.
    >
    > require 'rmail' ==> require 'rubymail'
    > RMail::Message ==> RubyMail::Message
    >
    > This rename is somewhat random, but rectifies something I think I got
    > wrong from the start (not matching the package name with the package's
    > module name space).


    mmm RubyMail was packaged as rubymail (not *rmail*); how should I name
    the new one?

    > It also marks the beginning of what I plan to be
    > another active and comparably unstable phase of RubyMail development,
    > so it makes some sense to do this now.


    Yes, looks like the perfect occasion for a "soname change".

    --
    Hassle-free packages for Ruby?
    RPA is available from http://www.rubyarchive.org/
     
    Mauricio Fernández, Nov 18, 2004
    #14
  15. Mauricio Fernández <> writes:

    > mmm RubyMail was packaged as rubymail (not *rmail*); how should I name
    > the new one?


    You may wish to wait a while, or call it rubymail1, etc.


    >> It also marks the beginning of what I plan to be another active and
    >> comparably unstable phase of RubyMail development, so it makes some
    >> sense to do this now.

    >
    > Yes, looks like the perfect occasion for a "soname change".



    --
    matt
     
    Matt Armstrong, Nov 19, 2004
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mauricio Fernández

    [ANN] rpa-base 0.1.0 "kitanai"

    Mauricio Fernández, Jun 16, 2004, in forum: Ruby
    Replies:
    7
    Views:
    179
    Mauricio Fernández
    Jun 21, 2004
  2. Mauricio Fernández

    [ANN] rpa-base 0.2.0

    Mauricio Fernández, Aug 6, 2004, in forum: Ruby
    Replies:
    11
    Views:
    283
    Mauricio Fernández
    Aug 10, 2004
  3. Ruben
    Replies:
    5
    Views:
    123
    David Ross
    Aug 18, 2004
  4. Mauricio Fernández

    [ANN] rpa-base 0.2.1pre1

    Mauricio Fernández, Aug 22, 2004, in forum: Ruby
    Replies:
    3
    Views:
    114
    Mauricio Fernández
    Aug 23, 2004
  5. Mauricio Fernández

    [ANN] rpa-base 0.2.2

    Mauricio Fernández, Sep 30, 2004, in forum: Ruby
    Replies:
    1
    Views:
    133
    David Ross
    Oct 1, 2004
Loading...

Share This Page