Redhat Package Manager for OSX
- Thread starter 01000111
- Start date
kilowatt
mach-o mach-o man
Well, before I installed mac os X final release, I had to wipe my drive. Before I wiped it, I copied some stuff off it, such as the usuall linux command line utilities (bash, ls, top, netstat, cat, pico , etc). None of them will execute in X from the command line. I get something like : incompatable binary
Of course, my linux distro was Yellow Dog Linux (www.yellowdoglinux.com, I think). So maby yours will be different. And, srpm's are another story.
But to answer your question, I don't know how to open an rom file in osx, maby if you could compile the rpm utility... yeah right!
Of course, my linux distro was Yellow Dog Linux (www.yellowdoglinux.com, I think). So maby yours will be different. And, srpm's are another story.
But to answer your question, I don't know how to open an rom file in osx, maby if you could compile the rpm utility... yeah right!
There is a port in the works- and working to some degree.
The ppc binaries in a Linux RPM will not work in Darwin.
However, src.rpm's are a nice place to get source taralls from... if you can open them.
You can almost always find sources though in tarball format on the web. Look at http://www.freshmeat.net/
The ppc binaries in a Linux RPM will not work in Darwin.
However, src.rpm's are a nice place to get source taralls from... if you can open them.
You can almost always find sources though in tarball format on the web. Look at http://www.freshmeat.net/
strobe
Puny Member
RPMs are horrible. Avoid at all costs, even if you're using Linux.
Anyway I want to clarify some things:
LinuxPPC and Darwin use different binary formats and link to different libs using a different linker. NetBSD PPC can run LinuxPPC binaries using a compatibility library (currently a beta) based on the same code which allows FreeBSD to execute Linux x86 code. However getting this to work on Darwin would take more effort that it's worth.
LinuxPPC doesn't run anything which we don't have the source to. Linux x86 have a few binary-only titles but LinuxPPC does not.
If you want a nice source distribution system check out www.openpackages.org which has a goal of making a common ports system for all major BSD OSs including FreeBSD, NetBSD, OpenBSD, and Darwin.
* If you want source don't get SRPM, get a .tar.gz or get it from cvs.
Anyway I want to clarify some things:
LinuxPPC and Darwin use different binary formats and link to different libs using a different linker. NetBSD PPC can run LinuxPPC binaries using a compatibility library (currently a beta) based on the same code which allows FreeBSD to execute Linux x86 code. However getting this to work on Darwin would take more effort that it's worth.
LinuxPPC doesn't run anything which we don't have the source to. Linux x86 have a few binary-only titles but LinuxPPC does not.
If you want a nice source distribution system check out www.openpackages.org which has a goal of making a common ports system for all major BSD OSs including FreeBSD, NetBSD, OpenBSD, and Darwin.
* If you want source don't get SRPM, get a .tar.gz or get it from cvs.
why? I think rpms are a hell of a lot better than almost any other packaging format, for many reasons. why do you think they're no good? ever try downgrading a solaris package? and can you even remove macosx packages?
no seriously, I think the openports idea is a good one, finally a ports tree that has the goal of working for all bsds. but I'd rather see something like the software update (which has the capability of being like debian's apt) that can talk to multiple repositories, not just apple (imagine, select something from download.com's software repository just by selecting it in software update, and having software update install all the dependencies as well).
curious about your dislikes of rpm..
cheers,
-o
no seriously, I think the openports idea is a good one, finally a ports tree that has the goal of working for all bsds. but I'd rather see something like the software update (which has the capability of being like debian's apt) that can talk to multiple repositories, not just apple (imagine, select something from download.com's software repository just by selecting it in software update, and having software update install all the dependencies as well).
curious about your dislikes of rpm..
cheers,
-o
well yes and no, all of redhat's rpms have crazy dependencies (try installing any newish rpm on a 6.2 box.. nope? then try the src.rpm, and then you see you have to upgrade 30 more rpms to satisfy dependencies)..
but just the format itself I think is a really good one. the religious debate about rpm vs dpkg is a hot one, but the real difference is this: rpms do not do configurations in the package for the most part, whereas dpkgs a lot of the time have you interactively do configuration after the package installation. this is both good and bad, but when you're trying to roll out a new apache package to 30+ boxes, you probably do your config mgmt elsewhere anyway. and that difference is on purpose, because of the ideals of the two groups who designed rpm and dpkg. I prefer rpm.
but the foremost reason I chose rpm for my own projects over dpkg is its cross-platform functionality. you can have src.rpms which can be built on multiple platforms and architectures with no problems (now of course, most that I have seen have problems because that functionality is still rather immature, and the packagers tend not to do it right in any case).
well let me close saying that I've really not had too much exposure to dpkgs since I was running slink on my alpha about 2 years ago. but I managed to get a system up and running which would make equivalent a redhat intel box and a sparc solaris box as far as package mgmt went, and then I could install multi-arch/os rpms built from the same src rpm. very nice..
you should check out this project, quite cool, and that set of rpms doesn't have the crazy dependencies that the redhat built rpms do:
http://www.fastcoder.net/~thumper/software/sysadmin/snapdragon/
rpm distributions for solaris 2.6, 2.7, and slackware 7.1. if I ever get the time, I'd love to extend platform support to solaris 8 and darwin. maybe digital unix too if I can free up one of my alphas to run DU. shouldn't be too difficult.
cheers,
-o
but just the format itself I think is a really good one. the religious debate about rpm vs dpkg is a hot one, but the real difference is this: rpms do not do configurations in the package for the most part, whereas dpkgs a lot of the time have you interactively do configuration after the package installation. this is both good and bad, but when you're trying to roll out a new apache package to 30+ boxes, you probably do your config mgmt elsewhere anyway. and that difference is on purpose, because of the ideals of the two groups who designed rpm and dpkg. I prefer rpm.
but the foremost reason I chose rpm for my own projects over dpkg is its cross-platform functionality. you can have src.rpms which can be built on multiple platforms and architectures with no problems (now of course, most that I have seen have problems because that functionality is still rather immature, and the packagers tend not to do it right in any case).
well let me close saying that I've really not had too much exposure to dpkgs since I was running slink on my alpha about 2 years ago. but I managed to get a system up and running which would make equivalent a redhat intel box and a sparc solaris box as far as package mgmt went, and then I could install multi-arch/os rpms built from the same src rpm. very nice..
you should check out this project, quite cool, and that set of rpms doesn't have the crazy dependencies that the redhat built rpms do:
http://www.fastcoder.net/~thumper/software/sysadmin/snapdragon/
rpm distributions for solaris 2.6, 2.7, and slackware 7.1. if I ever get the time, I'd love to extend platform support to solaris 8 and darwin. maybe digital unix too if I can free up one of my alphas to run DU. shouldn't be too difficult.
cheers,
-o
IMNSHO Apple ought to beef up their PAX-based system and do two fairly straightforward things:
1. Fix the problems inherent in PAX. A few installers have been distributed for MacOS X that do silly things like erasing directories and changing file permissions. A little tighter checking would eliminate this issue.
2. Add a basic installer logging system. The Receipts directory contains only a hint of what was installed and doesn't promote user awareness. But frankly the old method of writing a text file named "Installer Log" has got to die now that users are meant to only deal with their home directories and documents. Apple should develop a simple logging format - say maybe... um... XML? - and create a lovely Aqua interface to manage installs and uninstalls.
Now lest this sound too close to the Windows Registry or the old notion of installing an uninstaller this could be expanded to a nice maintenance system which would let you back up your old install before upgrading it, and could leverage hooks into the low level file system to watch ANY installer and log its activity.
The reason I think Apple would be willing to actually perform such a project is the same as the reason they created Sherlock and iTunes. Those tools give users an edge for the tasks they perform all the time, which should be quick and painless. Installing is something we all have to live with, and it wouldn't hurt to have a well-honed front end.
1. Fix the problems inherent in PAX. A few installers have been distributed for MacOS X that do silly things like erasing directories and changing file permissions. A little tighter checking would eliminate this issue.
2. Add a basic installer logging system. The Receipts directory contains only a hint of what was installed and doesn't promote user awareness. But frankly the old method of writing a text file named "Installer Log" has got to die now that users are meant to only deal with their home directories and documents. Apple should develop a simple logging format - say maybe... um... XML? - and create a lovely Aqua interface to manage installs and uninstalls.
Now lest this sound too close to the Windows Registry or the old notion of installing an uninstaller this could be expanded to a nice maintenance system which would let you back up your old install before upgrading it, and could leverage hooks into the low level file system to watch ANY installer and log its activity.
The reason I think Apple would be willing to actually perform such a project is the same as the reason they created Sherlock and iTunes. Those tools give users an edge for the tasks they perform all the time, which should be quick and painless. Installing is something we all have to live with, and it wouldn't hurt to have a well-honed front end.