Omer Zak wrote: > >> >> CPAN Perl modules generally get a package in Debian as well. It follows >> that I can rebuild them like that as well. >> > > All of them? > All those packaged are packaged. It's unlikely that all those in CPAN are packaged. I'm not sure which you meant. > >> And a similar answer, yes. >> > > My actual experience was that the Eclipse PHP plugin is not in Debian > Etch. If I'll need this plugin before Lenny becomes stable, I'll have > to install the plugin outside of Debian packaging system. > Or pull the source from sid and run the procedure above, hoping it works.
Here's the nice part, if pulling the source from sid doesn't work, it is highly likely that trying to compile it on Etch will break stuff. This means that the "manually fixing" is really necessary. > >> If the best does not >> happen, you have to fix stuff yourself. >> > > "you have to fix stuff yourself" - is not a scalable solution, in the > general case. It is impossible for any system to encapsulate everything, and it is impossible for any system to accommodate everything it doesn't. It therefor follows that any solution (aside from side by side installations, as offered by Dan) is unacceptable to you. Please note that it may well happen that it is not only impossible to build a program from another flavor on your main system, it may be that it is also impossible to run it. Not all conflicts go away once the program is compiled. If that happens, what do you propose to do? > > >> Yes, if you want to break stability, you run the risk that stability >> will be broken. Just work with Sid and if that's the case, though. >> > > Nowadays, it is not necessary to break stability. We have fat hard > disks, and we have virtualization. This combination means that only > dunces (and people duncified by tightfisted PHBs) break stability. > > In another message, Dan Armak suggested to use Gentoo, and cited also > support for different versions of toolchain components needed by > different projects. chroot installing another system is a very possible option. Debian, in fact, has a tool designed solely for bootstrapping a chrooted Debian system. The problem, as I mentioned above, is that there is only one port 80, only so many syslogs that can run simultaneously, and only one file called "/usr/bin/php", or, for that matter, "/bin/sh". True non-easilly solvable conflicts may arise not only during build, but during attempted use as well. That's why, as far as I'm concerned, there is no real difference between a chroot different (or another) distro install, a VM and a true different machine. If you want the programs to work apart, each of the above works (with its own limitations). If you want all environments to work together, none of them applies. Shachar ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
