some rpm building questions

some rpm building questions

[Bo Forslund]

Hello!

I have some questions about how to pack a guile rpm.


Would rpm packaging like this be good? Or should all .h files go to a
-devel package?


guile
	/usr/bin/*

libguile
	/usr/lib/libguile/*

libguile-devel
	/usr/include/libguile.h
	/usr/include/libguile/*

guile-lib
	/usr/share/aclocal/guile.m4 
	/usr/share/doc/*
	/usr/share/guile/1.6.0/ice-9/*
	/usr/include/guile/gh.h
	(/usr/share/guile/1.6.0/scripts/*)    ???

guile-oop
	/usr/share/guile/1.6.0/oop/*

guile-srfi
	/usr/share/guile/1.6.0/srfi/*
	/usr/lib/libguile-srfi-*


guile-readline
	/usr/include/guile-readline/readline.h 
	/usr/lib/libguilereadline-v-12.*
	
guile-ltdl
	conflicting libltdl here already

I don't know where to put /usr/share/guile/1.6.0/scripts/*. Should it go
to it's own package or to the guile or guile-lib package?

And then libltdl. As there already is one installed, can it just be
omitted or shall it go to a package? But then, how can it be installed
if there is a conflicting one installed already.

Well.. this is the rpm spec so far.

And curiously,  What does ice-9 stand for.

Bo



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: some rpm building questions

[Bo Forslund]

The spec ended up packing like this. Is it OK? And how about ltdl? Can
the old one be replaced? Can libtool use this libltdl if the old one is
replaced?

Bo


guile
	/usr/bin/guile

libguile12
	/usr/bin/{guile-config, guile-snarf, guile-tools}
	/usr/share/guile/1.6.0/{ice-9,oop,scripts}
	/usr/share/info/guile.info*, r5rs.info}
	/usr/lib/{libguile.*, libguilereadline*}

libguile12-devel
	/usr/share/aclocal/guile.m4
	/usr/include/guile/*
	/usr/include/guile-readline/*
	/usr/include/libguile/*
	/usr/include/libguile.h
	
guile-srfi
	/usr/share/guile/1.6.0/srfi/*
	/usr/lib/libguile-srfi*

guile-ltdl
	/usr/lib/libltdl.*
	/usr/include/ltdl.h





_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: some rpm building questions

[Han-Wen Nienhuys]

bo.forslund@abc.se writes:
> The spec ended up packing like this. Is it OK? And how about ltdl? Can
> the old one be replaced? Can libtool use this libltdl if the old one is
> replaced?
> 
> Bo
> 
> 
> guile
> 	/usr/bin/guile


For which distribution is this spec?  It would be nice if packages
were named to something like

	guile1.6

so that you can install multiple (binary incompatible) releases next
to each other.  This would be especially cool for RedHat, since GUILE
1.6 managed to slip past the RedHat 8 release date (making guile 1.4
the RH standard for the coming years.)

> The spec ended up packing like this. Is it OK? And how about ltdl? Can
> the old one be replaced? Can libtool use this libltdl if the old one is
> replaced?

I wouldn't opt for that many subpackages.  The space savings would be
small, and it confuses users.  I'd rather have a single guile and
guile-devel package;

-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl    | http://www.cs.uu.nl/~hanwen/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: some rpm building questions

[Marius Vollmer]

Bo Forslund <bo.forslund@abc.se> writes:

> The spec ended up packing like this. Is it OK?

I think Rob can comment on this better than I can.

> And how about ltdl? Can the old one be replaced? Can libtool use
> this libltdl if the old one is replaced?

We are going to release a Guile-1.6.1 soon (hopefully) that does not
use a conflicting libltdl.  You may want to wait for this.
Alternatively, if the RPM format allows this, you can replace the old
libltdl with the one from Guile.  It is completely compatible and only
fixes a few (significant) bugs.

> guile
> 	/usr/bin/guile
> 
> libguile12
> 	/usr/bin/{guile-config, guile-snarf, guile-tools}
> 	/usr/share/info/guile.info*, r5rs.info}

These should probably go to libguile12-devel.  You wont be able to
install two versions of libguile when its package contains unversioned
files, like guile-config.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: some rpm building questions

[rm]

On Fri, Oct 04, 2002 at 02:30:04PM +0200, Marius Vollmer wrote:
> Bo Forslund <bo.forslund@abc.se> writes:
> 
> > The spec ended up packing like this. Is it OK?
> 
> I think Rob can comment on this better than I can.
> 
> > And how about ltdl? Can the old one be replaced? Can libtool use
> > this libltdl if the old one is replaced?
> 
> We are going to release a Guile-1.6.1 soon (hopefully) that does not
> use a conflicting libltdl.  You may want to wait for this.
> Alternatively, if the RPM format allows this, you can replace the old
> libltdl with the one from Guile.  It is completely compatible and only
> fixes a few (significant) bugs.

Are you shure about this? If i understand it right it changes the behavior
of libltdl, or? There might be apps (admittedly, broken) that depend on
exactly this behaviour. 

  Ralf

P.S.: i might be playing devil's advocate here, but if some apps start loding
different libs after installation of the "better" libltdl Bo might have some
serious problems.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: some rpm building questions

[Rob Browning]

rm@fabula.de writes:

> Are you shure about this? If i understand it right it changes the behavior
> of libltdl, or? There might be apps (admittedly, broken) that depend on
> exactly this behaviour. 

We will be providing libguile-ltdl, and libguile will link against
it.  We will provide no headers for any of the libguile-ltdl
functionality, but dynamic-link and friends will be using it.

This has already been done, though I haven't finished committing the
second half of the work that mvo started, and so far it fixes the
problems listed below (most reported upstream in November of last year
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120169&repeatmerged=yes).

We will also probably be adding support for /etc/ld.so.conf and
/usr/local/lib/ on the platforms where we already know it makes sense.

2002-10-04  Rob Browning  <rlb@defaultvalue.org>

	* guile-ltdl.c: Remove custom realloc. (#define rpl_realloc
	realloc).  You can't define realloc like this unless you also
	define malloc.  This is a quick hack for now; we may want
	something cleaner later.
	(memcpy): coerce ptrs to (char *) before copying characters
	through them -- I can't recall for sure, but I believe this was
	causing an overrun error at times.
	(realloc): commented out -- as mentioned above, you can't define
	your own malloc unless you know enough about the malloc in use to
	be able to tell how big the src ptr is.  The disabled code
	incorrectly used the *destination* ptr to decide how much to copy.
	This sometimes results in out-of-bound accesses which cause
	segfaults.
	(tryall_dlopen_module): check to be sure (dirname_len > 0) before
	testing first character against '/'.
	(try_dlopen): check for feof(file) in read loop -- otherwise
	infloop?
	(scm_lt_dlopenext): remove unused variable file_found.

2002-10-04  Marius Vollmer  <mvo@zagadka.ping.de>

	* guile-ltdl.c: Renamed all exported functions and variables to have a
	"scm_lt_" prefix.
	(try_dlopen): Set newhandle to null when try_all_dlopen failed.
	(scm_lt_dlopenext): Reverse test of "file_not_found()".
	Previously, we would stop searching when the file wasn't found
	yet, while we should continue in that case.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: some rpm building questions

[Rob Browning]

Bo Forslund <bo.forslund@abc.se> writes:

> I have some questions about how to pack a guile rpm.
>
>
> Would rpm packaging like this be good? Or should all .h files go to a
> -devel package?

One of the things that's been holding up the debian packages is that
I've been trying to make sure I get this right -- the debian packages
are already mostly right, but not completely.

First off, make sure to name your source package with the major
version information, i.e. guile-1.6, not just guile.  This prevents
(for example) distributions from losing the source to 1.4 even if the
binaries are still on their servers when 1.6 comes out.

With respect to the binary packages, my current thinking is:

  guile-1.6
    for the main app binary, etc.

  libguile12
    for ice-9, libguile, etc. -- this must be versioned so you can
    later have apps that link against libguile9 and libguile12
    installed at the same time.  If you don't allow that, then you
    can't incrementally upgrade your system.

  guile-1.6-dev
    should "provide guile-dev" and "conflict guile-dev".
    Until/unless we have a way to have several sets of headers
    installed and some way to specify which to use, you can't really
    allow multiple development packages to be installed at the same
    time, but is is useful to be able to switch back and forth between
    two versions.  This package should contain the the headers, etc.

  libguile-srfi-srfi-4-v-1
    similar to libguile12, but for the srfi lib.

  libguile-srfi-srfi-13-14-v-1
    similar to libguile12, but for the srfi lib.

  libguilereadline-v-12
    similar to libguile12, but for readline.

  libqthreads12
    similar to libguile12, but for qthreads.

Note that one might raise an objection to so many library packages,
especially with the version numbers in the name, but if you don't do
that you're in big trouble later on.  Trivial example: imagine we
release guile 1.8 with libguile.13.so, but we leave
libguile-srfi-srfi-4-v-1 at major number 1.  If we had just put all
the srfi libs in libguile, then the guile 1.8 libguile package and the
guile 1.6 libguile package would have conflicting files.

The general rule is: if you don't want to get in trouble later,
*always* package publically visible, directly linkable shared
libraries in their own packages, and put the major number in the name
so you can have more than one version installed at the same time.

I'm planning to fill out README-PACKAGING in full after I finish
working out the debian packages -- when I'll know more, but this is
what's in my head at the moment.

> guile-ltdl
> 	conflicting libltdl here already

If you can, I'd hold off until we get 1.6.1 ready -- I'm hoping within
a couple of days -- this issue will go away and stay there.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: some rpm building questions

[Marius Vollmer]

rm@fabula.de writes:

> > Alternatively, if the RPM format allows this, you can replace the old
> > libltdl with the one from Guile.  It is completely compatible and only
> > fixes a few (significant) bugs.
> 
> Are you shure about this? If i understand it right it changes the
> behavior of libltdl, or? There might be apps (admittedly, broken)
> that depend on exactly this behaviour.

Yes, good point.  If you are worried about this, please wait for 1.6.1.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel