On Mon, 2003-06-23 at 13:03, Bob Proulx wrote: > Rob Weir wrote: > > Mark L. Kahnt wrote: > > > I have this myself, and the installation scripts use 'rpm' to attempt > > > the installation, which on Debian just won't work, period. > > Not even with "The Gross Hack" of creating an rpmdb? The Intel C/C++ > compiler could be described using exactly the same description used to > describe IBM's db2 in the previous messages. I install it by picking > it apart and reassembling because I am a purist. I end up with a > clean installation. (If the license allowed it I could make the .debs > available. But it does not and so I can't.) But I do know at least > one individual who does the rpm installation just for that bundle of > software. Since it does not state any rpm requires in the bundle it > actually works. Scary. But an option. As long as one understands > how the rpmdb works and can turn it on and off at will I could > compromise and recommend that proceedure. Turn it on for this > installation, then turn it off again afterward by moving the rpmdb out > of the way until next time. > > I mention the Intel packages because it is likely that the IBM > packages will have some similar problems. At the time someone puts a > shell script installer around an installer like rpm it is usually > because they want to do bad things and so will be doing bad things. > Human nature is almost predictable for some things. > > > > It *could* be done by editing the installation scripts to replace > > > 'rpm' with 'alien' for any actual installation calls. While the > > > LSB is a great solution to > > > > You could write a script that runs something like: > > > > alien -t deb $2 && dpkg -i `echo "$2"|sed -e 's/\.deb$/\.rpm/' > > And don't forget alien's -i, --install option! :-) Just do it in one > step. > > > and drop it in your $PATH so it's run instead of the normal 'rpm'. Or > > something. > > I have really thought seriously of trying that. But in the case of > the Intel compiler it just uses rpm as a glorified tarball carrier of > the files. After installation it munges the files setting paths in > them and moving some around. So it won't verify cleanly after an > install. Which is very slimy in my book. I would hate to have > something in the dpkg database that was not really there since the > install shell script munged it or moved it. > > One important note about alien. I think it is really great and > certainly the way to go. But the version in woody has some serious > bugs which can keep you from having a good experience with it. I > highly recommend pulling the unstable source and backporting it to > woody. It backports easy. The latest versions have some very > important bug fixes. Even with the newest version, however, I have > some issues. But Joey has been very active working on it of late and > I think the release for sarge will be in excellent shape. > > Bob To me, the thought of two separate package databases (Debian, RPM) in use at once makes me shudder, as leaving the room for each to overwrite important files installed by the other. It is why, when I do build software from source, it goes on /opt or /usr/local, and 'alien' gets used when I *must* turn to a .rpm - someday I will learn the details to write the debian/ scripts, strictly grab source when it isn't in the Debian archives, and keep everything kosher. Alternately, I might send IBM the CDs for Woody and some documentation on building .debs (pointers to policy, etc.) with some encouragement that .debs are of significant use on servers and "those of us who know better" ;) -- Mark L. Kahnt, FLMI/M, ALHC, HIA, AIAA, ACS, MHP ML Kahnt New Markets Consulting Tel: (613) 531-8684 / (613) 539-0935 Email: kahnt@hosehead.dyndns.org
Attachment:
signature.asc
Description: This is a digitally signed message part