I was thinking about some of the issues raised involving ruby libraries
and various packaging systems raised on the list in the past day or two.
One of the things raised was a desire to see ruby packages integrate
well with the packaging system on the system you use, be it Gentoo,
Debian, RedHat or even Windows.
RAA-Install could be extended to generate packages in any or all of
these packaging systems - perhaps even to do a batch generation that
would allow for example the entirety of the RAA to be available as part
of say Gentoo or Debian.
The stumbling block, as well as being RAA-Install’s biggest outstanding
problem, is the variety of packaging styles included in RAA.
All that needs to happen is for all packages to adhere to the de-facto
standards already widely adopted, such that packages are:
a) packaged as tar.gz
b) use either:
- Minero Aoki’s install.rb/setup.rb, or
- automake/autoconf (./configure; make; make install)
c) Have correct download and version information available in the RAA
In particular they need to support the --prefix=PATH option, so that
packages can be installed in non-root locations as required by many of
the packaging systems.
If all packages support the following, RAA-Install will work and in
addition we can support all RAA packages in the various distribution
specific packaging formats.
So is it time to require that RAA packages conform to these rules?
So is it time to require that RAA packages conform to these rules?
In light of the benefits, I personally say “Yes!”
Packages not offering a --prefix option or (Better) some sort of
DESTDIR/–root option often don’t get installed by me. It’s just too
much work to pack up properly in case I want to remove it – besides, if
it’s worth using, it gets installed on at least five systems – if I
package it, I only have to do the hard work (making it non-invasive)
once.
All that needs to happen is for all packages to adhere to the de-facto
standards already widely adopted, such that packages are:
a) packaged as tar.gz
b) use either:
Minero Aoki’s install.rb/setup.rb, or
automake/autoconf (./configure; make; make install)
automake/autoconf would be hard to get working on a Windows systems.
c) Have correct download and version information available in the RAA
In particular they need to support the --prefix=PATH option, so that
packages can be installed in non-root locations as required by many of
the packaging systems.
Now, for the compiled packages, prefix/destdir would be enough for me. In
fact, I would suggest a ‘raa’ script so you could just do a:
$ raa configure prefix=/usr/local destdir=/tmp/lala-1234
< ‘raa’ does stuff here >
$ raa build
< ‘raa’ builds it >
$ su
< enter root password here. >
$ raa install
< install goes here >
< system specific commmands to make a package out of /tmp/lala-1234 go here >
…and we require that all packages on the RAA have a ‘raa’ script that
supports this interface. Now, ‘raa’ could be calling some other script behind
our back, we don’t care so long as it supports the ‘raa’ interface.
Here’s another idea: If a package meets our ‘no compiling needed, all
files are in the right directory’ specs, (whatever that turns out to be: I
would suggest a specially named directory in the tarball that can just be
dropped into somewhere in $LOAD_PATH) the raa script in the package
tarball would contain a
Please excuse my ignorance, but what’s the difference/benefit?
Thanks,
-Tom
···
On Sun, 2003-06-15 at 23:31, Aredridel wrote:
So is it time to require that RAA packages conform to these rules?
In light of the benefits, I personally say “Yes!”
Packages not offering a --prefix option or (Better) some sort of
DESTDIR/–root option often don’t get installed by me. It’s just too
much work to pack up properly in case I want to remove it – besides, if
it’s worth using, it gets installed on at least five systems – if I
package it, I only have to do the hard work (making it non-invasive)
once.
App providers should say whether their app conforms to the rules.
A small, obvious graphic on the app’s RAA entry, and against it in
all the indexes. (A bright red gem seems useful and appropriate)
There should be a feedback button on RAA, so it’s very easy to for
any users of the app to report any non-conformance if it turns out
to be non-conformant.
Quoteing androflux@softhome.net.remove.to.reply, on Tue, Jun 17, 2003 at 01:41:01PM +0900:
All that needs to happen is for all packages to adhere to the de-facto
standards already widely adopted, such that packages are:
a) packaged as tar.gz
b) use either:
- Minero Aoki’s install.rb/setup.rb, or
- automake/autoconf (./configure; make; make install)
automake/autoconf would be hard to get working on a Windows systems.
Most people don’t have cygwin installed, and lots don’t have MSDev
either. So they don’t get to install binary packages?
I think windows needs binary installs, and that means that RAA needs a
machine that will build binary versions of packages by non-windows users
for windows users.
But —> check out cmake.org, cmake is yet another way to make
makefiles, but it can also output MSDEV project files. By doing so, it
would at least allow the packages to be built if the windows user had
MSDEV, and there could be binary of cmake on RAA if raa-install needed
to download it.
So does anything requiring c-code. Including stuff using extconf.rb.
My thoughts are that for Windows we need a binary packaging system,
perhaps integrated with the Windows versions of ruby. Once all the
packages are compliant it should be straightforward to build all of the
RAA-Packages as a batch.
Personally, I’ve not built any C-packages on Windows (except cygwin but
that’s a bit different). How is it done? Is it usually done through VC++
or some other way? Is it possible to build ./configure scripts to build
things that don’t depend on the cygwin dll?
-Tom
···
On Tue, 2003-06-17 at 00:41, Jason Creighton wrote:
On Mon, 16 Jun 2003 12:21:21 +0900 > Tom Clarke tom@u2i.com wrote:
All that needs to happen is for all packages to adhere to the de-facto
standards already widely adopted, such that packages are:
a) packaged as tar.gz
b) use either:
- Minero Aoki’s install.rb/setup.rb, or
- automake/autoconf (./configure; make; make install)
automake/autoconf would be hard to get working on a Windows systems.
I think this is correct. What we need to the RAA-Packages to do is to be
buildable on Windows, but not necessarily trivially buildable. We’ll
never make it easily buildable as most Windows users don’t even have a
compiler.
So, for Windows it’s a question of ‘is it possible rather than is it
easy?’
-Tom
···
On Tue, 2003-06-17 at 08:36, Sam Roberts wrote:
Most people don’t have cygwin installed, and lots don’t have MSDev
either. So they don’t get to install binary packages?
I think windows needs binary installs, and that means that RAA needs a
machine that will build binary versions of packages by non-windows users
for windows users.
Packages not offering a --prefix option or (Better) some sort of
DESTDIR/–root option often don’t get installed by me. It’s just too
much work to pack up properly in case I want to remove it – besides, if
it’s worth using, it gets installed on at least five systems – if I
package it, I only have to do the hard work (making it non-invasive)
once.
Please excuse my ignorance, but what’s the difference/benefit?
With --prefix, you’re telling a package it’s final home: /usr,
/usr/local, or /, or /opt/ruby/pacages/ruby-foo. It may very well
hard-code those values in as places to look for data – in applications
written in C, it’s very common for the compiler to compile in
“/usr/share/appname” as the data directory if /usr is the prefix –
obviously, using --prefix=/tmp/builder/package/usr is bad if the app,
once installed, is going to look in /tmp for it’s data files.
DESTDIR is a common addition to Makefiles for this purpose, and some
programs like RPM and Poldek have a --root option that has the same
idea: tell the system it’s final prefix, but say that during
installation, it will prepend another root that won’t be remembered
after install.
Personally, I think it’s possible… although
if a Windows user wants to compile a C program,
that user needs a C compiler. (Your daily message
from the Department of Obviousness.)
I think there are freeware (older) versions of
Borland compilers and maybe even Micro$oft.
What I think I’d prefer is: Write everything to
the standard of gcc (for Windows); and make a
Windows gcc available on the RAA for the increased
convenience of Windows users.
Hal
···
----- Original Message -----
From: “Tom Clarke” tom@u2i.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, June 17, 2003 10:51 AM
Subject: Re: Standardizing Installers
I think this is correct. What we need to the RAA-Packages to do is to be
buildable on Windows, but not necessarily trivially buildable. We’ll
never make it easily buildable as most Windows users don’t even have a
compiler.
So, for Windows it’s a question of ‘is it possible rather than is it
easy?’
Personally, I’ve not built any C-packages on Windows (except cygwin but
that’s a bit different). How is it done? Is it usually done through VC++
or some other way? Is it possible to build ./configure scripts to build
things that don’t depend on the cygwin dll?
There’s the mingw toolchain: GNU that compiles against msvcrt32.dll,
instead of cygwin.dll.
automake/autoconf would be hard to get working on a Windows systems.
So does anything requiring c-code. Including stuff using extconf.rb.
But not nearly as hard as getting a UNIX shell script to run on Windows.
My thoughts are that for Windows we need a binary packaging system,
perhaps integrated with the Windows versions of ruby. Once all the
packages are compliant it should be straightforward to build all of the
RAA-Packages as a batch.
I agree: Most people don’t have a compiler on their Windows systems, so a
binary packaging system would make it easier for them.
Jason Creighton
···
On Wed, 18 Jun 2003 00:39:22 +0900 Tom Clarke tom@u2i.com wrote:
One idea would be to add a field to RAA for “raa-install compatible?”.
The values would be “yes”, “no” or “included in Ruby standard
distribution as of Ruby version #{ruby_version}”.
Packages not offering a --prefix option or (Better) some sort of
DESTDIR/–root option often don’t get installed by me. It’s just too
much work to pack up properly in case I want to remove it – besides, if
it’s worth using, it gets installed on at least five systems – if I
package it, I only have to do the hard work (making it non-invasive)
once.
Please excuse my ignorance, but what’s the difference/benefit?
With --prefix, you’re telling a package it’s final home: /usr,
/usr/local, or /, or /opt/ruby/pacages/ruby-foo. It may very well
hard-code those values in as places to look for data – in applications
written in C, it’s very common for the compiler to compile in
“/usr/share/appname” as the data directory if /usr is the prefix –
obviously, using --prefix=/tmp/builder/package/usr is bad if the app,
once installed, is going to look in /tmp for it’s data files.
One thing I’ve found in my month or so of using ruby is that most
RAA packages (not a dig at raa, that’s just sll I’ve used) don’t
listen to things like --prefix , but insist on reading the Config
module to figure out where to go.
This is a major PITA if you don’t have root, and generally involves
taking a hacksaw to install.rb.
ri (which is so useful that it really should be in 1.8, just to
cross-pollinate another thread) in particular needs
some major surgery if you’re a mere mortal user.
Of course, there’s quite possibly something I’m missing (see my other
posts here for sone idea of my newbity), but for people with a shell
account this can be the difference between using ruby or Perl for a
given job… I think it should be addressed
if a ‘recommended’ package format is being proposed.
Minero Aoki’s install.rb/setup.rb supports this option already, doesn’t
it? IIRC, they are both the prefix (where it will reside) and the
install prefix (where it is temporarly installed) are set with --prefix.
This may be a little confusing…
From a spec file of mine:
[…]
%build
ruby install.rb config --prefix=/usr
ruby install.rb setup
[gus@comp tenant2]$ ruby install.rb --version
install.rb version 3.1.2
Guillaume.
···
On Mon, 2003-06-16 at 00:43, Aredridel wrote:
Packages not offering a --prefix option or (Better) some sort of
DESTDIR/–root option often don’t get installed by me. It’s just too
much work to pack up properly in case I want to remove it – besides, if
it’s worth using, it gets installed on at least five systems – if I
package it, I only have to do the hard work (making it non-invasive)
once.
Please excuse my ignorance, but what’s the difference/benefit?
With --prefix, you’re telling a package it’s final home: /usr,
/usr/local, or /, or /opt/ruby/pacages/ruby-foo. It may very well
hard-code those values in as places to look for data – in applications
written in C, it’s very common for the compiler to compile in
“/usr/share/appname” as the data directory if /usr is the prefix –
obviously, using --prefix=/tmp/builder/package/usr is bad if the app,
once installed, is going to look in /tmp for it’s data files.
DESTDIR is a common addition to Makefiles for this purpose, and some
programs like RPM and Poldek have a --root option that has the same
idea: tell the system it’s final prefix, but say that during
installation, it will prepend another root that won’t be remembered
after install.
I suppose the “Raa-installable flag” was already mentioned.
For what it’s worth, I’d love to see it.
Don’t forget that not every package wants to be installed
···
il Mon, 16 Jun 2003 14:35:23 +0900, Mark Wilson mwilson13@cox.net ha scritto::
One idea would be to add a field to RAA for “raa-install compatible?”.
The values would be “yes”, “no” or “included in Ruby standard
distribution as of Ruby version #{ruby_version}”.
>