How to not collaborate with Debian (and upstream)

[Emmet Hikory]

Scott Kitterman wrote:
> ... Gems, as
> has been the subject of recent discussion on Ubuntu ML about why this was
> NOT a good idea, pretty thoroughly ignore the entire package management
> systems.  Putting them in the path so random versions not installed by the
> package management system get executed in the place of system installed
> version is not my idea of a good plan.
>
> ... The best way to avoid this
> kind of backblast is to work out sensible solutions with Debian and
> upstream.

    Note that this may take time, but can be very rewarding.  Within
the Java team, we've been working with Sun and Fedora towards finding
a solution that allows maven-enabled builds of Java packages to work
in the repositories.  While there are still a couple different
solutions that have been identified and are in discussion on the spec,
by engaging multiple interested parties, we are discovering a way that
we can both 1) allow a system designed for internet updates of
packages during builds, and 2) maintain the advantages of a coherent
packaging system.  A large part of this work involves discussions as
to the goals of the software, and working to ensure that a common
solution can be identified that meets the needs of upstream,
distributors, developers, and end-users.  It is unlikely that a
solution will be in place before intrepid+1, but when it arrives, it
can be expected to be the correct solution.

    This is a markedly different process, and it can be said that it
does not serve the end-users well in the short term, but it is very
much more likely to result in soemthing which can be supported and
become the standard shared throughout all distributions and developers
than something implemented whilst still under discussion and debate.
(and note that the final solution is unlikely to either download
arbitrary unreviewed code without specific user instruction or
interfere or replace any aspect of the existing package management
system).

    As another example, with which I am slightly less familar, we do
support python's distutils, including compents that may be used on
end-user systems to download the very most recent code from the
internet.  For most cases, we have developed workarounds and
conventions that ensure a pleasant environment for python development
without reliance on this code, and have a very active team working on
both Debian and Ubuntu to ensure that this remains the case.  While we
may currently have fewer Ruby developers than Python developers, I
would think a similar model ought apply, and that we could gain
similar benefits.

-- 
Emmet HIKORY