* some rpm building questions @ 2002-10-03 22:06 Bo Forslund 2002-10-04 2:20 ` Bo Forslund 2002-10-04 16:04 ` Rob Browning 0 siblings, 2 replies; 8+ messages in thread From: Bo Forslund @ 2002-10-03 22:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: some rpm building questions 2002-10-03 22:06 some rpm building questions Bo Forslund @ 2002-10-04 2:20 ` Bo Forslund 2002-10-04 11:56 ` Han-Wen Nienhuys 2002-10-04 12:30 ` Marius Vollmer 2002-10-04 16:04 ` Rob Browning 1 sibling, 2 replies; 8+ messages in thread From: Bo Forslund @ 2002-10-04 2:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: some rpm building questions 2002-10-04 2:20 ` Bo Forslund @ 2002-10-04 11:56 ` Han-Wen Nienhuys 2002-10-04 12:30 ` Marius Vollmer 1 sibling, 0 replies; 8+ messages in thread From: Han-Wen Nienhuys @ 2002-10-04 11:56 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: some rpm building questions 2002-10-04 2:20 ` Bo Forslund 2002-10-04 11:56 ` Han-Wen Nienhuys @ 2002-10-04 12:30 ` Marius Vollmer 2002-10-04 13:08 ` rm 1 sibling, 1 reply; 8+ messages in thread From: Marius Vollmer @ 2002-10-04 12:30 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: some rpm building questions 2002-10-04 12:30 ` Marius Vollmer @ 2002-10-04 13:08 ` rm 2002-10-04 15:48 ` Rob Browning 2002-10-08 21:27 ` Marius Vollmer 0 siblings, 2 replies; 8+ messages in thread From: rm @ 2002-10-04 13:08 UTC (permalink / raw) Cc: Bo Forslund, guile-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: some rpm building questions 2002-10-04 13:08 ` rm @ 2002-10-04 15:48 ` Rob Browning 2002-10-08 21:27 ` Marius Vollmer 1 sibling, 0 replies; 8+ messages in thread From: Rob Browning @ 2002-10-04 15:48 UTC (permalink / raw) Cc: Marius Vollmer, Bo Forslund, guile-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: some rpm building questions 2002-10-04 13:08 ` rm 2002-10-04 15:48 ` Rob Browning @ 2002-10-08 21:27 ` Marius Vollmer 1 sibling, 0 replies; 8+ messages in thread From: Marius Vollmer @ 2002-10-08 21:27 UTC (permalink / raw) Cc: Bo Forslund, guile-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: some rpm building questions 2002-10-03 22:06 some rpm building questions Bo Forslund 2002-10-04 2:20 ` Bo Forslund @ 2002-10-04 16:04 ` Rob Browning 1 sibling, 0 replies; 8+ messages in thread From: Rob Browning @ 2002-10-04 16:04 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-10-08 21:27 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-10-03 22:06 some rpm building questions Bo Forslund 2002-10-04 2:20 ` Bo Forslund 2002-10-04 11:56 ` Han-Wen Nienhuys 2002-10-04 12:30 ` Marius Vollmer 2002-10-04 13:08 ` rm 2002-10-04 15:48 ` Rob Browning 2002-10-08 21:27 ` Marius Vollmer 2002-10-04 16:04 ` Rob Browning
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).