Standardizing Installers 
Author Message
 Standardizing Installers

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?

-Tom

  signature.asc
< 1K Download


Fri, 02 Dec 2005 11:21:21 GMT  
 Standardizing Installers

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



Fri, 02 Dec 2005 11:31:25 GMT  
 Standardizing Installers

Quote:

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

Please excuse my ignorance, but what's the difference/benefit?

Thanks,

-Tom

  signature.asc
< 1K Download


Fri, 02 Dec 2005 12:21:56 GMT  
 Standardizing Installers

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

Ari



Fri, 02 Dec 2005 12:43:55 GMT  
 Standardizing Installers
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}".


Fri, 02 Dec 2005 13:35:23 GMT  
 Standardizing Installers

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

--
Rasputin :: Jack of All Trades - Master of Nuns



Fri, 02 Dec 2005 18:23:25 GMT  
 Standardizing Installers

Quote:
> > So is it time to require that RAA packages conform to these rules?

> In light of the benefits, I personally say "Yes!"

IMO, we should initially modify RAA slightly.

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.

Cheers,
    Euan



Fri, 02 Dec 2005 20:35:24 GMT  
 Standardizing Installers
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

%install
rm -rf $RPM_BUILD_ROOT
mkdir $RPM_BUILD_ROOT
ruby install.rb install --prefix=$RPM_BUILD_ROOT
[...]


install.rb version 3.1.2

Guillaume.

Quote:

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

> Ari



Fri, 02 Dec 2005 22:05:17 GMT  
 Standardizing Installers

scritto::

Quote:
>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}".

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 :)



Sat, 03 Dec 2005 06:17:34 GMT  
 Standardizing Installers
On Mon, 16 Jun 2003 12:21:21 +0900

Quote:

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

Quote:
>    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

require 'install-this-package-without-compiling-because-it-does-not-need-it'

...or something with a slightly less verbose name. :-)

Jason Creighton



Sat, 03 Dec 2005 10:36:14 GMT  
 Standardizing Installers

Quote:

> On Mon, 16 Jun 2003 12:21:21 +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.

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

  signature.asc
< 1K Download


Sat, 03 Dec 2005 23:39:22 GMT  
 Standardizing Installers

Quote:
> -----Original Message-----

<snip>

> 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

InstallShield.  And no, I don't know how. :/

Regards,

Dan



Sat, 03 Dec 2005 23:48:28 GMT  
 Standardizing Installers

Quote:

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

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

  signature.asc
< 1K Download


Sat, 03 Dec 2005 23:51:13 GMT  
 Standardizing Installers

Quote:
> > -----Original Message-----

> <snip>

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

Well, I know that djgpp works fine for me
on Windows. (This is the DeLorie version
of gcc -- may not be latest -- not sure
why it's called that, but the executable
is just gcc.exe as you'd expect).

Now, having said that, I have *not*
compiled Ruby on Windows (though I have
on other platforms, of course). Nor have
I tried to install a Ruby package that
needed a C compiler. I should try that.

At any rate, I've heard that this is
theoretically possible with VC++ (and I
think there are even build notes for it).
So I think it should be possible with a
Windows gcc also (without Cygwin, which I
haven't used lately).

Hal



Sun, 04 Dec 2005 01:08:21 GMT  
 Standardizing Installers

Quote:
----- Original Message -----


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

--
Hal Fulton



Sun, 04 Dec 2005 01:12:42 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Standardized Collection Classes NEEDED BADLY!!!!

2. Standardizing case sensitivity

3. Standardized dictionary hacking

4. Size of core, standardized i/o

5. Size of core, standardized i/o

6. When to standardize

7. Standardizing Logo

8. Standardizing Logo

9. Gary Stager is hopping mad about standardized tests.

10. standardized scripting embeddable languages

11. Web Virtual Reality Becomes More Standardized - iWORLD

12. Standardized library managers

 

 
Powered by phpBB® Forum Software