[ubuntu-mono] [Bug 357555] Re: Block Mono updates from Debian, and simplify packaging

[Michael B. Trausch]

On Wed, 22 Apr 2009 10:01:47 -0000
directhex <directhex at 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 MOTU Mono
Team, which is subscribed to mono in ubuntu.