First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 28148
Alias:
Product:
Component:
Status: RESOLVED
Resolution: DUPLICATE of bug 32956
Assigned To: Daniel Ahlberg (RETIRED) <aliz@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: John Clemens <clemej+gentoobug@deater.net>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 28148 depends on: Show dependency tree
Bug 28148 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2003-09-07 21:54 0000
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

------- Comment #1 From Patrick Kursawe 2003-11-17 08:31:06 0000 -------
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 ***

First Last Prev Next    No search results available      Search page      Enter new bug