Le lundi 16 février 2009 à 22:33 +0100, Matthias Klose a écrit : > > I really like the idea of using the same location for both tools, please > > note > > that you'll have to change pycentral to use something like /usr/lib/pyshared > > (for Python extensions) > > where is the advantage of having a /usr/lib/pyshared?
Robustness. When you have a directory of Python modules that is an autogenerated symlink farm, you need to be able to rebuild it from scratch if anything goes wrong. This brings the packaging helper to the same level of robustness as dpkg itself. > > I don't like python (<< X.Y) dependencies, it's so... old-policy like. > > Not a good idea, IMHO > > well, just "not liking" is a weak argument. Having to regularly re-upload all architecture-independent packages without any gain sounds like a less weak one. > As I did write above, the support for namespace packages should be implemented > using diversions. It's ok to generate these by a packaging helper. Generating diversions automatically is doomed to fail. Diversions are fragile, and they should be the exception, not the rule. What do you do when more than 2 packages need the same empty __init__.py ? -- .''`. Debian 5.0 "Lenny" has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and `- told that if you don't install Lenny, he'd melt your brain.
signature.asc
Description: Ceci est une partie de message numériquement signée
