Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Not sure what category to put this under... The ebuild screipt for magic is, err.. broken, but still installs about half the files anyway and declares "success". I don't see how it ever worked, actually. to reproduce, simply try emerging it, and you'll discover that the compilation fails, but it will still install a bunch of "stuff" (althought not the actual 'magic' binary) and never who and error beyond the compilation messages. Here are the problems I've discovered, along with some fixes for them that I've come up with. 1) the source -needs- to run "make config" on a clean source tree in order for the "database.h" file to be generated (and a few others). the current ebuild doesn't do this. this is the cause of the compilation failures. 2) "make config" requires some input.. this is a little tricky. my solution is to simply supply a file in ${FILESDIR} that contains all the answers and < that into the make config program. It seems to work fine on x86, but we may need a different one for other archs, etc. I'm open to suggestions. 3) Because i implemented #2 the way I did, I needed to modify one line in the generated config file to make the install bath ${DESTDIR}/usr and not hardcoded to /usr. 4) finally, with that all sone, it compiles fine and installs. but the resulting binary is looking for things installed in the "/usr/share/lib/magic", when it appears everythign else is still installed in /usr/lib/magic. This is done because of the "-fhs" patch that's installed, but the binaries are still installe din the wrong place. I've not fixed this yet, as it's late and I'm tired. And before anyone yells, i maintain this is no more kludgy then the original ebuild ;) Here's the diff from the old ebuild script to my new one. I'm not a gentoo developer, just a hacker, so i'm sure there are other ways to clean this up as well. I'm open to suggestions..please take this as a starting point.: diff -u magic-7.1-r1.ebuild magic-7.1-r2.ebuild --- magic-7.1-r1.ebuild 2003-09-06 18:38:40.000000000 -0400 +++ magic-7.1-r2.ebuild 2003-09-07 23:05:51.000000000 -0400 @@ -18,14 +18,21 @@ src_unpack() { unpack ${A} - # Patch to use FHS paths + einfo "Patch to use FHS paths" patch -p1 < ${FILESDIR}/${P}-fhs.patch - # Patch for GCC 3.2 compatibility + einfo "Patch for GCC 3.2 compatibility" patch -p1 < ${FILESDIR}/${P}-gcc3.2.patch - # Insert our idea of configuration file - cp ${FILESDIR}/defs.mak-${PV}-r1 ${S}/defs.mak + # Need to run "make config" because that script generates some + # necessary files for us. Choose some good defaults. + einfo "Configuring" + CAD_HOME=/usr + cd ${S} && make config < ${FILESDIR}/config.input-${PV}-r2 >& /dev/null + # CADDIR needs to be ${DESTDIR}/usr, instead of the default. + sed 's/^CADDIR.*/CADDIR\t\t\t= ${DESTDIR}\/usr/' defs.mak > new.mak + mv new.mak defs.mak + cd .. # Clean up all the pre-GCC-3.2 preprocessor directives einfo "Cleansing preprocessor directives" And the file "config.input-7.1-r2" that's put in ${FILESDIR} is : 1 1 1 yes yes yes yes yes yes yes yes yes yes yes I hope this helps someone... been a fun couple of hours deciphering ebuild and emerge ;) john.c
Finally working a bit further on it... not yet fixed, but moving at least :-) See the newer bug for any progress announcements. *** This bug has been marked as a duplicate of 32956 ***