On Fri, Oct 26, 2007 at 02:22:42PM -0700, Mike Orr wrote: > On 10/26/07, zunzun <[EMAIL PROTECTED]> wrote: > > On Oct 26, 8:42 am, Christoph Haas <[EMAIL PROTECTED]> wrote: > > > > > > Actually not. But I'm a bit tired of voicing my opinion and I can > > > imagine that others may be tired of my opinion either. > > Your opinion is fine, I've just been burned by Debian-unstable a > couple times and had to reinstall my system, especially when something > centeral like libc or X or /etc/nsswitch.conf changes.
Yes, it can be risky. And "unstable" users are supposed to know how to find the cause of problems and how to fix bugs. Nothing for the faint-hearted and parents-in-law. :) > Then there are packages that depend on something not available yet, or > depend on themselves.... Dependency problems shouldn't appear in "unstable". At least I haven't seen any yet. > As for making debs oneself, that's a bigger learning > curve than I want to invest time in. Right. The package management is very sophisticated and so is the process. I would never claim that it's easy to create a Debian package. The learning curve for a minimal package is a day. Don't get me started about complex software with multiple packages being generated from one source package. > (Why do I have to create a PGP key to sign my package? Nobody except > me will be using it!) You don't. Just use "-uc -us" as parameters to debuild or dpkg-buildpackage and signing will be skipped. The signature is there to make sure that only packages signed by Debian developers are accepted into the official repositories. > There are programs like debhelper that do the work for you, but then > you're at the mercy of some mysterious and magical program that you're > not really sure what it's doing. And they are written in Perl, too. :) Or you use CDBS which makes build scripts be only a few lines long but you'll never know what they do then because they are pure undocumented Make magic. Actually debhelpers are fine tools but you'll need to learn about each of them. It's more common for Debian developers to maintain several software packages rather than each (upstream) developer doing the debianisation themselves. > Setuptools has its own problems. If you install several packages that > each have lots of dependencies, you end up with package soup. It > doesn't uninstall. But you can keep these problems manageable by > using virtualenv et al -- just delete the whole sandbox if you have > problems, spend 15 minutes building a new one (you've got all your > dependencies listed in your app's setup.py, right?), and you're ready > to go. Full ack. Formerly I was a fan of using the system-wide Pylons version. But I had to agree that this would break Pylons applications that rely on 0.9.4 and are suddendly faced with new version and might break. So for deployment I think I'll use a sandbox myself, too. It's fine to do the system-wide approach on my development workstation though. Christoph --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
