CPAN Style installer

ruby-talk
21

Well the main feature that uses the whole list is the --showall option. I
could avoid pulling back the list, unless that option was used. I would
love to have more details about the XML-RPC interface, is that available
anywhere.?

If you download and extract the XML-RPC tar file, it creates a samples
directory, with (among other things) code for querying RAA. You can ask for
stuff by category, name, a few other things.

You get back an array of hashes of arrays (or something like that). I found it
less than intuitive, so I started on a class that wraps the results and creates
a set of flat RaaItem objects, with simple attributes (e.g. name, owner, ID,
download_url).

I then wrote some code that iterates over a set of such objects and produces
either RSS 0.9 or RDF/RSS 1.0.

Then I got busy with life stuff …

XML-RPC has some other dependencies, though I don’t think they require
compiling C code. There’s an XML parser needed in there someplace.

James

22

why the lucky stiff ruby-talk@whytheluckystiff.net writes:

I wonder. Is it fair to simply install these directly in
$prefix/lib/ruby/site_ruby/$version? (aka Config::CONFIG[‘sitelibdir’])

I have a suggestion: why not install each package to its own
directory, then foreach file in the package, make a link to
$prefix/lib/ruby/site_ruby/$version/.

YS.

23

In article 20021108204309.GA49642@rysa.inetz.com,

···

why the lucky stiff ruby-talk@whytheluckystiff.net wrote:

JamesBritt (james@jamesbritt.com) wrote:

BTW, the entire RAA XML file is around 14K lines. Maybe I missed it in your
original post, but why do you want to read the entire thing, and how
often would
you want to do it?

I just sent a patch to Tom which will use Apache’s ETag header to detect
any changes and cache the XML file once it’s been pulled. This
significantly aleviates the amount of data raa-install is pulling down
the line.

Some packages are simple *.rb files, though. Rimport, for example.

I wonder. Is it fair to simply install these directly in
$prefix/lib/ruby/site_ruby/$version? (aka Config::CONFIG[‘sitelibdir’])

What if we either have it ask the user if that’s ok or have a commandline
option which will do that?

Phil

24

Doesn’t work with Windows.

IMO, it is fair to install them in the appropriate place.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.11.08 at 17.37.42

···

On Sat, 9 Nov 2002 07:24:10 +0900, Yohanes Santoso wrote:

why the lucky stiff ruby-talk@whytheluckystiff.net writes:

I wonder. Is it fair to simply install these directly in
$prefix/lib/ruby/site_ruby/$version? (aka
Config::CONFIG[‘sitelibdir’])
I have a suggestion: why not install each package to its own
directory, then foreach file in the package, make a link to
$prefix/lib/ruby/site_ruby/$version/.

25

I wonder…can you make links on a windows machine?

Signed,
Holden Glova

···

On Sat, 09 Nov 2002 11:24, Yohanes Santoso wrote:

why the lucky stiff ruby-talk@whytheluckystiff.net writes:

I wonder. Is it fair to simply install these directly in
$prefix/lib/ruby/site_ruby/$version? (aka Config::CONFIG[‘sitelibdir’])

I have a suggestion: why not install each package to its own
directory, then foreach file in the package, make a link to
$prefix/lib/ruby/site_ruby/$version/.

YS.

26

Austin Ziegler austin@halostatue.ca writes:

why the lucky stiff ruby-talk@whytheluckystiff.net writes:

I wonder. Is it fair to simply install these directly in
$prefix/lib/ruby/site_ruby/$version? (aka
Config::CONFIG[‘sitelibdir’])
I have a suggestion: why not install each package to its own
directory, then foreach file in the package, make a link to
$prefix/lib/ruby/site_ruby/$version/.

Doesn’t work with Windows.

Well, the rational is this: if you ever want to manually scrap a
package and update it, just delete a directory. Why would you want to
update it manually? Because sometimes, you really need the latest
package (which may not be compatible with the previous version and
requires thoroughly scrapping the old ones), but the package in
raa-suc (or whatever) is a bit outdated.

Without putting each package in its own directory, removing old files
from a package involves a fair amount of hunting and guess work.

IMO, it is fair to install them in the appropriate place.

The question is not whether it’s fair or not. After all lots of
systems already stuff everything in one place (witness /usr/bin). The
question is whether we allow cruft/bad practice to continue or not.

The good thing from a packager like Debian’s is it allows you to find
out all the files of a package (‘dpkg -L perl’ would list all files
from the perl package) and allows thorough uninstall. The bad thing is
it requires the package builder to manually/semi-automatically
identify all files.

So, instead, the easiest way is to stuff a package in its own
directory. The advantage is you can have two version of the same
package installed which sometimes comes in handy. To use a particular
version, just link it in (see GNU stow
http://www.gnu.org/software/stow/stow.html).

I’m not too sure about windows, but I think if you use libcygwin, you
can do file linking. Alternatively, ruby’s include path could be
appended with the appropriate package directory for each installed
package.

Just my 2c.
YS.

···

On Sat, 9 Nov 2002 07:24:10 +0900, Yohanes Santoso wrote:

27

Could this maybe done without using sym-links.

I notice that a convension is emerging to package files in a directory
named after the package name. E.g.:
site-ruby/1.6/mypackage.rb
site-ruby/1.6/mypackage/supportlib1.rb
site-ruby/1.6/mypackage/supportlib2.rb
site-ruby/1.6/mypackage/supportlib3.rb

What if something like a index.html was allowed so that:
site-ruby/1.6/mypackage/index.rb

was allowed?

If it was, a smart installer could automatically put badly behaving
libraries in a sub dir.

Would this work?

-Tom

···

On Sat, 9 Nov 2002, Yohanes Santoso wrote:

Austin Ziegler austin@halostatue.ca writes:

On Sat, 9 Nov 2002 07:24:10 +0900, Yohanes Santoso wrote:

why the lucky stiff ruby-talk@whytheluckystiff.net writes:

I wonder. Is it fair to simply install these directly in
$prefix/lib/ruby/site_ruby/$version? (aka
Config::CONFIG[‘sitelibdir’])
I have a suggestion: why not install each package to its own
directory, then foreach file in the package, make a link to
$prefix/lib/ruby/site_ruby/$version/.

Doesn’t work with Windows.

Well, the rational is this: if you ever want to manually scrap a
package and update it, just delete a directory. Why would you want to
update it manually? Because sometimes, you really need the latest
package (which may not be compatible with the previous version and
requires thoroughly scrapping the old ones), but the package in
raa-suc (or whatever) is a bit outdated.

Without putting each package in its own directory, removing old files
from a package involves a fair amount of hunting and guess work.

IMO, it is fair to install them in the appropriate place.

The question is not whether it’s fair or not. After all lots of
systems already stuff everything in one place (witness /usr/bin). The
question is whether we allow cruft/bad practice to continue or not.

The good thing from a packager like Debian’s is it allows you to find
out all the files of a package (‘dpkg -L perl’ would list all files
from the perl package) and allows thorough uninstall. The bad thing is
it requires the package builder to manually/semi-automatically
identify all files.

So, instead, the easiest way is to stuff a package in its own
directory. The advantage is you can have two version of the same
package installed which sometimes comes in handy. To use a particular
version, just link it in (see GNU stow
Stow - GNU Project - Free Software Foundation).

I’m not too sure about windows, but I think if you use libcygwin, you
can do file linking. Alternatively, ruby’s include path could be
appended with the appropriate package directory for each installed
package.

Just my 2c.
YS.

28

Austin Ziegler austin@halostatue.ca writes:

why the lucky stiff ruby-talk@whytheluckystiff.net writes:

I wonder. Is it fair to simply install these directly in
$prefix/lib/ruby/site_ruby/$version? (aka
Config::CONFIG[‘sitelibdir’])
I have a suggestion: why not install each package to its own
directory, then foreach file in the package, make a link to
$prefix/lib/ruby/site_ruby/$version/.
Doesn’t work with Windows.
Well, the rational is this: [snip]

I understand, but I still don’t think it’s a useful thing. Better to
allow:

install --as-user

This would install into $HOME rather than lib/ruby/site_ruby; it
makes it possible to have a “user-site” separate from the host site.

Without putting each package in its own directory, removing old
files from a package involves a fair amount of hunting and guess
work.

Shouldn’t. Package installers should know exactly where they install
things.

IMO, it is fair to install them in the appropriate place.
The question is not whether it’s fair or not. After all lots of
systems already stuff everything in one place (witness /usr/bin).
The
question is whether we allow cruft/bad practice to continue or not.

I personally don’t think it’s bad practice.

The good thing from a packager like Debian’s is it allows you to
find out all the files of a package (‘dpkg -L perl’ would list all
files from the perl package) and allows thorough uninstall. The
bad thing is it requires the package builder to
manually/semi-automatically identify all files.

ALL packagers should know what was installed and where; if they
don’t, then there’s a problem (even RPM knows this stuff). Windows’
problem with this lies primarily with the fact that there’s no
single installer location (install logs are installed with the
application).

So, instead, the easiest way is to stuff a package in its own
directory. The advantage is you can have two version of the same
package installed which sometimes comes in handy. To use a
particular
version, just link it in (see GNU stow
Stow - GNU Project - Free Software Foundation).

Frankly, I think stow is a dumb idea.

I’m not too sure about windows, but I think if you use libcygwin,
you can do file linking. Alternatively, ruby’s include path could
be appended with the appropriate package directory for each
installed package.

cygwin isn’t an option for standard use – libcygwin isn’t a useful
solution for me. Further, appending a directory to package to the
include may either be invalid (I’m not sure whether or not it is in
the environment and what the size limit is, anymore) or approaching
silly (removing the advantages of having a lib directory).

If Ruby required cygwin to use at this point, I wouldn’t be using
it.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.11.08 at 18.21.08

···

On Sat, 9 Nov 2002 08:13:42 +0900, Yohanes Santoso wrote:

On Sat, 9 Nov 2002 07:24:10 +0900, Yohanes Santoso wrote:

29

Austin Ziegler austin@halostatue.ca writes:

ALL packagers should know what was installed and where; if they
don’t, then there’s a problem (even RPM knows this stuff). Windows’

I agree that all package manager should know what and where they
install! But, like I said in the example with Debian’s package
manager, for the package manager to know all installed files, it
requires some additional work from the package builder.

If the package consists of exclusively ruby files, then the package
builder can just assume that that’s all in that package. Howeveer, if
a package needs to be compiled, and the compilation produces a bunch
of object files, then the person doing the packaging have to add
manually/semi-automatically each created object files and/or config
files into the list of files of that package.

The sane response would be to compile at the packager’s machine and
bundle the produced binary. But then, now the packager have to handle
many different platform. Not to mention that some packages compile
differently depending on what libraries you have in your machine. If
so, then how do you guarantee that the libraries in the packager’s
machine is similar to the libraries in your machine? What if you are
missing a functionality because the packager’s machine lack an
optional library? So, binary packaging is, well, an awkward solution
which require intensive work on the part of the builder.

GNU stow is a solution towards this put-all-in-one-place thinking. You
may not like it the way it works, but you gotta love the simplicity it
produces.

For example, in Debian, kde3 is still not officially included. So, you
download and compile the kde3, and then install it in
/usr/local/stow/kde-3.0.4. A week later, you want to upgrade to
kde-3.0.5, so just install it in /usr/local/stow/kde-3.0.5, and
perform ‘stow -D kde-3.0.4’ to remove the link from the old kde, and
‘stow kde-3.0.5’ to link the just-compiled kde. A year later, Debian
finally include kde3 officially. So, you want to remove kde-3.0.5 in
favour of the official kde package. No sweat.

Finally, installing a package in your own home directory may work in
some cases. But what if you’re working with a group of people. In this
case, the sensible solution is to install the package in a centrally
accessible place. May be in Windows where only one person works on a
machine, there is no difference between home directory installation
vs. central installation.

My point is, DOS had it right by putting each application in its own
directory. Windows had it wrong. Unix, CPAN, etc. also had it
wrong. There’s no sense in continuing an otherwise bad practice.

libcygwin, for all its faults, have managed to implement link in
Windows filesystem. Even if libcygwin has more faults than goodness,
there are many other UNIX emulations layer that implements file link
in Windows. Furthermore, it should be noted that it is possible to
pick just what you want from a library, especially one whose source
code is open.

YS.

30

Austin Ziegler austin@halostatue.ca writes:

ALL packagers should know what was installed and where; if they
don’t, then there’s a problem (even RPM knows this stuff).
Windows’
I agree that all package manager should know what and where they
install! But, like I said in the example with Debian’s package
manager, for the package manager to know all installed files, it
requires some additional work from the package builder.

This is a problem of the package manager, frankly. The only time
that this is something that could require work on the matter of the
package maintainer is for files generated during installation –
like Perl when it generates its HTML help files during installation
(at least on Windows using the AS installer).

If the package consists of exclusively ruby files, then the
package builder can just assume that that’s all in that package.
Howeveer, if a package needs to be compiled, and the compilation
produces a bunch of object files, then the person doing the
packaging have to add manually/semi-automatically each created
object files and/or config files into the list of files of that
package.

This applies only when you’re compiling the file(s) from scratch,
which may not always be the case. It is also possible to have the
packaging system parse the makefile(s) used to determine the targets
which need to be included. (Then again, I’m curious how the package
system would know which binary items to install in the first place,
and why telling the package this couldn’t also initiate the build
process, if necessary.)

GNU stow is a solution towards this put-all-in-one-place thinking.
You may not like it the way it works, but you gotta love the
simplicity it produces.

Actually, I don’t like stow at all, because it depends on symbolic
links, which is not a remotely useful solution except on Unix boxes
– and I personally wouldn’t use stow on my Unix boxes at all.
(Ultimately, stow doesn’t solve the problems of single
installation places, which are conflicting dynamic library versions,
and instead adds an unnecessary indirection.)

For example, in Debian, kde3 is still not officially included.
[…]

Um … when I tried Debian (for all of two hours when I decided that
the installation process sucked so much that I didn’t want to deal
with it), KDE3 was included.

Finally, installing a package in your own home directory may work
in some cases. But what if you’re working with a group of people.

Most package installers on unix support the specificaion of
alternate prefixes – allowing installation in $HOME, /usr, or
anything else.

In this case, the sensible solution is to install the package in a
centrally accessible place. May be in Windows where only one
person works on a machine, there is no difference between home
directory installation vs. central installation.

You’re completely wrong here. There is, at least with all NT-based
versions, and to some degree with 9x versions, limited ways of
supporting “local” installations. (NT-based versions have
significantly more flexibility here.) There is actually a difference
in installation.

My point is, DOS had it right by putting each application in its
own
directory. Windows had it wrong. Unix, CPAN, etc. also had it
wrong. There’s no sense in continuing an otherwise bad practice.

Stow, however, doesn’t fix the actual problem with this allegedly
bad practice. The problem here isn’t /usr/lib or
\windows\system32, but with conflicting library versions and no
clean way of managing it. Stow doesn’t fix this. Neither does going
back to statically compiled binaries or replicating libraries in the
directories of all binaries.

libcygwin, for all its faults, have managed to implement link in
Windows filesystem.

No, it hasn’t. It simulates it by creating files that point to the
actual file. It’s not a filesystem solution. It only works on
programs which use the filesystem functions in libcygwin itself –
which is a tiny percentage of the programs which would be used in
any given Windows installation.

Even if libcygwin has more faults than goodness, there are many
other UNIX emulations layer that implements file link in Windows.
Furthermore, it should be noted that it is possible to pick just
what you want from a library, especially one whose source code is
open.

Sorry, but it isn’t possible – because the OS filesystem itself is
closed.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.11.08 at 19.19.56

···

On Sat, 9 Nov 2002 08:58:08 +0900, Yohanes Santoso wrote: