On Wed, 22 Apr 2009 10:01:47 -0000 directhex <direct...@apebox.org> wrote:
> Absolutely, categorically, never going to happen. Here are a few > reasons: > > 1) Including Tomboy and F-Spot goes from taking 54.4 MiB (including > required Mono) to 141 MiB. The added bloat makes Mono impossible to > include in the install CD. Okay, so don't put Tomboy or F-Spot on the install CD. Or, add Banshee and remove some other (equivalent) unmanaged software and associated translations and free up space, since with every managed software application present the effective cost of having the CLR and class libraries around goes down. Or, maybe consider shipping CD images that have extremely targeted translations present, maybe having a download model like Firefox does, where users select their language on the Web site and then download an installer that contains support for that language. Being nifty and all, Ubuntu could do this and generate the CDs from a template and only include the options selected by the user, and cache that for a while for the next user(s) that download that particular translation-set. I am sure that the space savings on the CD would not be insignificant. Maybe there are other ways to streamline space usage on the CD. Maybe dpkg needs a bug filed against it to gain support for using bz2 compression inside of .deb files, instead of the present .gz compression, or maybe support the much better 7-zip compression scheme in .deb packages. Maybe a look at the recently-released 'xz' compressor, which also yields very good compression ratios above what bzip2 achieves (and is now seeing use in the GNU project) would help. Again, the savings that would generate in space would likely not be insignificant. Or maybe ponder whether we even _need_ to use CDs for distribution anymore. At some point (fairly soon, if I had to hazard a guess) the base distribution of software for a desktop install is going to grow enough that it will require a DVD, anyway. Perhaps now is the time to consider that avenue, and use net-installers for everyone that doesn't want an initial, up-front download of the distribution (and wants to be pickier about what they install, which isn't the typical use-case for an end-user). After all, in today's world entire distributions no longer fit on a single Blu-Ray disc. > 2) Every bug fix forces re-download of more than 50 meg of package >From the Mono packager's viewpoint: If the Mono source package is re-built, this is the case anyway, as all installed packages are downloaded and then installed. In that use case (which is the one use case that upstream counts on, and that end-users that expect to download .NET software would count on), using a single package saves download time and overhead because it's in one file with one set of headers, instead of in ~100. >From the package system's viewpoint: This is a real bug in the implementation of the package manager, and should be filed as a bug there. The package management system should have some handling of binary diffs that make it easier to efficiently update large packages, including the CLR, the Java runtime, and OpenOffice.org. > 3) Undesirable components of Mono, such as System.Windows.Forms, are > included with EVERY install, rather than just the "safe" parts What are the "unsafe" parts? If there are _truly_ unsafe components in Mono, then they can be isolated together in their own space; say, Microsoft extensions to the CLR and BCL can all be put into a "mono-microsoft-extensions" package, which would "Enhances:" the "mono" package (which should contain the CLR and BCL from the ECMA specs). However, APIs are inherently safe (see the "in re Bilski", among other things). Reverse-engineering in most locales is also acceptable if it is for the purpose of interoperability, as long as there is no copied code. Short of Mono copying Microsoft source code and unlawfully relicensing it under a Free Software license, I don't see an issue causing any "unsafe" code to be installed. Additionally, if the C# compiler needs to be split out into its own package, fine. Three packages (mono, mono-microsoft-extensions, mono-csharp-compiler) are still way better than 100+ packages, and drastically easier to update from upstream when new releases are made. If there should be splits naturally though, upstream bugs should be filed to request that the splits occur upstream, simplifying and streamlining packaging in downstream projects and making broad user-testing easier. This relieves distributors from maintaining file-lists for splits. > 4) Ubuntu developers are forced to take full ownership of not only > Mono, but approx. 90 other source packages which would need to be > repackaged independently of Debian, requiring phenomenal increases in > manpower So shift the simplification effort upstream to Debian, making their lives easier, too. The current situation is so complex that it is far easier to repackage 2.4.0 from pristine sources than it is to update the current mono-pkg from Debian to update all of the components to the Mono 2.4.0 release. That's a real problem, especially in the use-case where a user downloads a pre-compiled .NET application that isn't managed by the package manager and finds that it won't run. The assumption will be "the system doesn't support it." It won't be, "I should check to see if parts of the runtime and class library aren't present and install those so that I can run my application." They would simply march their way back to whence they came. Also, packages such as Banshee work unmodified with Mono 2.4, so I don't see where a repackaging effort would need to take place. It would be nice if some of the older bugs in apt would disappear so that a single package could provide versioned dependencies for the software that already exists, but currently stub packages are required to obtain compatibility (at the package management level, that is). > As it happens, the packaging split is seen as a gold standard by > others, including Mono upstream and the Debian Java team, as a way to > get a truly small subset of a major framework installed whilst still > useful. The Debian Mono Group is considered a gold standard for > Debian-Ubuntu cooperation and teamwork. The Java team appears to have a much better set of splits, with the class library being self-contained. It looks like they are using the split to make the packages orthogonal such that installing -jre and -jdk doesn't also pull in the same set of (dependent) binaries. Splitting it up any more than that would be detrimental to the end-user's experience, especially if the default were to only install a subset of the standard libraries. There, it would seem that the additional requirements on the package maintainers would seem beneficial and outweigh the costs of having single, overlapping packages. That said, while Java's packages are split, they aren't as complex (there are only 9 packages). Fragmenting it any less would appear to require duplication of files in packages and additional "Conflicts:" (though I don't think that this is a bad thing, the jre and jdk could easily conflict with each other and packaging would become easier; the user wouldn't care how it is done, and it would save man-time, even if it did cost a bit more space on the servers and some duplicated time in the packaging on the build servers). Fragmenting them any more than they are, though would create issues with maintainability and the end-user experience, particularly if only select subsets are installed. Imagine what kind of issues the average end-user would have trying to get all of the class library components installed if the Java class libraries were split into 100 packages and they just want to use their single application. They would say "Hrm, this system doesn't support my application, but the Java install on (Windows|Fedora|Slackware|whatever) did," and march their merry way back back to wherever they came from. > Now, if what you're after is an easy way to install everything, then > you could file a bug with Mono in the Debian bug tracker, requesting a > metapackage to pull in the kitchen sink. It's been considered for a > while. Updatability? Flies in the face of stability, as far as core > frameworks are considered. Major updates to pretty much ANY framework > is a big undertaking, and shouldn't be done lightly. Every release, a > Mono is prepared which is reliable & ready for production use. It's > the distribution's duty to make it happen. Having been using Mono 2.4 since its release, I would consider it to be as ready for production use as Firefox 3.0 or Pidgin is. It also doesn't crash in normal operation that I have found, unlike either Firefox 3.0 or Pidgin, which crash on a fairly regular basis. Being easy to update does not inherently mean that stability is going to suffer. Being easy to update _does_ mean that it's easier to test and deploy newer releases of the software. It would certainly make it easier to run through the Experimental->Testing->Unstable->Stable process in Debian, and with quicker iterations at that. Sure, Mono 2.2 would not have likely made it out of Experimental, but Mono 2.4 would already be there if it were easy to update. Ubuntu could have also shipped Mono 2.4 in Jaunty, if they would have wanted to, or advanced users could have had Mono 2.4 packages already available for testing and adoption by users who need them by now. It is such a significant undertaking on the packaging end of it, though, and that scares people away. Not everyone that needs to be able to use Mono 2.4 has the ability to work with the source and install a parallel environment, or repackage to replace the system runtime. And certainly they don't want to remove the mono package altogether and update the runtime, since a stub mono package won't register with cil-common and thus libraries can't be late-installed into the GAC, so running it as the only CLR from source would then naturally mean that _everything_ that user wants would have to be stubbed by the user such that they could do the things that they need to do, and build _all_ of that from source. Not a friendly situation. > If you feel that strongly, try packaging it yourself in a PPA, a > standalone mono-latest package with its own GAC etc that lives in /opt > someplace where it doesn't conflict with the system. I have started such an effort, with great success, though my aim is to replace the system runtime, not install a parallel one. I have been running a parallel environment for development purposes and indeed now I am nearing deployment time, which means I must have that software installable on a production server and working with a minimum of fuss, and in a way that my client expects. I do not yet have all components of Mono repackaged, but I do have the base upstream package as well as libgdiplus and VB.NET repackaged and available, with more to follow---the goal is to have the entire stack such that I can run Banshee, MonoDevelop, and my client application all running on a fully-updated stack, where such updates are needed. Where they are not, components from Ubuntu will be used as-is, since I've no interest in reinventing the wheel. The issues that I have run into in doing so are all package-management related. Testing on the desktop shows that updating the system runtime to Mono 2.4 doesn't create any issues with Banshee, which is the one main (pre-packaged) CLR application that I use. The only big undertaking that I've run into, actually, is working around the package structure in the existing system---running applications works just fine (as well it should, since Mono releases are backwards-compatible). --- Mike -- I don't really know that anybody's proven that a random collection of people doing their own thing actually creates value. --- Steve Ballmer, 2007 -- Block Mono updates from Debian, and simplify packaging https://bugs.launchpad.net/bugs/357555 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs