El Mon, 21-09-2009 a las 21:27 -0400, Benjamin M. Schwartz escribió: > > (1) one could create a bundle on Windows, but not test it. > > I'm not thinking about Windows. I'm thinking about Linux. I don't use an > RPM-based distro, so I don't have the RPM tools lying around. I'm not > especially comfortable with RPM or cpio archives, and I'm not sure how to > inspect or create them. Same with .deb.
With Python setup utils, it can be as easy as creating an xo bundle: ./setup.py bdist_rpm or ./setup.py bdist_deb You don't need to know more than this to match and exceed the functionality of the bundleutils. rpm is also available as a package for Debian-based distros, but dpkg is not available for Fedora. > >> 2. Tell the unpacked manifest at a glance without unpacking. > > > > All package formats support this. > > RPM does not, because of the pre/post scripts. The scripts may generate > additional files. pre-post scripts are optional, rarely necessary, and can be disabled. Moreover, packages are required to "own" files they create from scripts, so you'd see them in the list output. As a matter of fact, I dislike the practice of using scripts in packages and I think it should be discouraged as much as possible. > >> 3. Be sure that no untrusted code needs to be run to perform the > >> installation. > > > > All package formats support this. > > I did not say "support sometimes". I said "be sure". Simplicity, so that > it is possible to reason about the installation process, is a virtue. > Using some restricted subset of the features of some existing format is > certainly possible, but also creates enormous potential for confusion. It's a necessary trade-off. You could obtain the desired feature set both by adding features to the xo bundles or by subtracting unwanted features from the full-blown package managers. The problem with the first approach is that it would take maybe 10 man/years of work to get there. And it would still result in uncorrectable dishomogeneity between the OS and the activities. So, all considered, which approach is worse? > > Actually, the ability to run scripts on installation is often requested > > by authors of content bundles. > > And this request should be denied, as should dependency handling. There are a few valid reasons for the former, and many compelling reasons for the latter. The current scheme is simply broken: it will create a compatibility nightmare within a few years, even on a single OS distribution and CPU architecture. Besides, it doesn't offer enough modularity for complex activities (GCompris) and forces developers of non-Python activities to do resort to horrible kludges to embed their runtimes within the bundles. How do you propose to address *all* this issue without introducing dependencies and a proper build system? > We are not going to solve the common real-world scenarios. It is > impossible for us. For example, we wish to operate on many different > distributions. You know better than I that this means that we cannot rely > on dynamic linking with dependencies, which is the most common real-world > scenario. How does, for instance, Gimp manage to work perfectly on *all* Linux distributions? And how do all the other 19K packages in my distro manage to find *exactly* all the dynamic libraries they need when they are installed? We don't have to do anything special, either. Some Sugar activities have already been natively packaged in the main Linux distributions. They work as well as any other packaged application, and none of the original authors need to be concerned about how this magic was performed. > What we can do is to create new, special, highly restricted scenarios, and > then demand that people package for them. One such scenario that I > believe we can support with confidence is Activities written exclusively > in Python, using only functions from a static list of blessed modules. Sorry, I find this horribly restrictive. My favorite educational application, XaoS, would not even be possible in this scenario. Neither would Firefox, GCompris and many of the most popular activities that we offer on activities.sugarlabs.org today. With such a limitation, Sugar would be a really sad educational environment. > I agree, switching bundle formats would gain us a lot of these features. > However, I don't think features such as dependency tracking are of much > use to us, because we can't trust system package managers, Why not? > and we can't > afford to maintain our own complete distro and package database. Why would we have to? Several good distros already exist... just pick one. No, actually, let's pick many! > The closest I can come to agreeing with this claim is to suggest 0install > [1]. 0install is a completely user-side package management system, with > support for multiple platforms, building from source, decentralized > storage, cryptographic bundle identification, and unprivileged > installation. It also comes with its own bundle format. The result is > almost as bad as maintaining our own parallel-installable distro, but at > least it's all already working. > > [1] http://0install.net/ It's pretty awesome... until you discover how it's done. Something very similar in scope, but much larger quite different in implementation, was already attempted a long time ago: http://www.desktoplinux.com/news/NS5197426928.html Red Carpet was capable of installing a whole replacement Gnome desktop on top of many distributions. Of course, it was a disaster: the complexity grew with the number of packages, distributions and possible upgrade paths. It would break your system in really interesting ways ;-) 0install seems cleaner and simpler, although on my system it failed to install the Subversion package with some weird error after downloading a bunch of packages. I'd replace the current bundle format with this any day, but it's far from being a solution. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel