On 11/16/2010 08:30 AM, Martin Pitt wrote: > = .desktop files = > > This wasn't discussed extensively, but some comments indicated that > making an exception for those for maverick should be okay. (Hasn't > been officially approved yet, though)
Noted. > = Python binaries = > Is that actually an issue? They could all live in /opt/<packagename>/, > we are mostly concerned about user-facing apps which ship a desktop > file? > > Do we have actual cases where those extra packages ship command line > applications or something which needs to be in $PATH? > > How would people think about the (maverick only) permission to ship a > symlink to /opt/... in /usr/local/bin? We're not overly concerned about binaries for user-facing apps, but it's worth deciding now if you're comfortable with the exception. A simple command-line interface corresponding to a simple desktop app does seem like a reasonable possibility. > = Python libraries = > > For maverick we could require app developers to add their application > path directory to sys.path, and fix quickly to do that automatically. > Would that be practical? For Natty, Didier has fixed Quickly, cdbs, python-support, and python-distutils-extra to handle /opt installation. But we can't backport those fixes to Maverick. (We can ignore Lucid, as we aren't targeting these apps to Lucid.) The core problem is that cdbs and dh_support (as shipped in Maverick) currently only support prefix=/usr for Python, when we need prefix=/opt/<appname> or prefix=/opt/<vendor>/<appname>. Our best alternative is to have the ARB manually modify the developer's source packages to add .install files forcing an /opt install. It's a little labor intensive, but we were already prepared to do more work for the Maverick ARB reviews, and there are really only 4 proposals in our queue anyway. We'll test this strategy on the existing applications in the queue before the next TB meeting. > pyc files are just a "nice to have", so we could ship maverick > packages without them. Yes, we can skip them for Maverick packages, the small loss in speed isn't a big problem for the lightweight apps we're considering. Python version symlinks we can probably also skip (since it's a custom app lib directory). > I didn't quite get why people asked for a vendor prefix in /opt/, like > /opt/ubuntu. What would this give us? AFAIK it wouldn't address any of > above problems, and just additionally require LANANA registration, > etc.? /opt is a common location for user-compiled applications and libraries, so even though we're not using it for any Ubuntu packages, there is a substantial risk of namespace collision. Also, the /opt/ubuntu vendor prefix (or whatever name) ultimately gives us a sensible location for installing .desktop files, and other files we want to move from the standard paths to /opt. An added question came up while I was pinning down the Python libs install of whether installing the legal data and package information under /opt instead of /usr/share/doc/<appname> is legal, or will be visible to other parts of the system. Legally it should be fine as long as we clearly state that /opt/<vendor>/<appname>/doc is the specified location for license files for lightweight apps. Allison -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
