[indiana-discuss] Re: Ok here come my 2c

[Eric Boutilier]

On Sun, 10 Jun 2007, stephen o'grady wrote:
>> I disagree with the notion for a "Opensolaris" packaging system. Let
>> every derived distro do its own packaging. We are the core, we are
>> neutral, we don't tell you what GUI to use, if you wan't WIN32 on top
>> of the core, go ahead and do it.
>>
>> This would be what I would call a core reference, which would also
>> make the binaries between real distros or however you want to call them
>> compatble, without the need of them being pure wishi washy if they
>> want to contain compatibility.
>
> if by compatibility you mean package format compatibility, then +1.
>
> while i agree to extent that you don't need a standardized packaging _system_ - though it seems silly to reinvent the wheel - having a common, agreed upon packaging _format_ is critical, as far as i'm concerned.
>
> one of the unfortunate consequences of the divergent innovation in the Linux model is that each distribution requires maintainers for the same packages. i.e. Debian has a MySQL package maintainer, Fedora has a MySQL package maintainer, Gentoo has a MySQL package maintainer, and so on.
>
> this is somewhat necessary given the parallel evolutionary tracks that Linux distributions have proceeded along, but it is redundant.
>
> as i've said before [1], and virtually everyone on list seems to agree, package management is fundamentally a must have going forward. decisions around packaging format, however, will go a long way towards determining a.) how much effort the Solaris family of distributions will have to invest in redundant effort and b.) how trivial or non-trivial it is for PMC's from the Linux world to bring their skillset over to the Solaris one if they should choose to.
>
> [1] http://redmonk.com/sogrady/2006/05/16/to-sun-good-job-on-on-the-jre-license-but-ive-got-another-job-for-you/
> _______________________________________________


Stephen,

The thing about b. (leveraging skill re-use in the binary package arena) is
that it means swearing-off the SVR4 binary package format, which of course
would come with huge tradeoffs. So it's not clear (to me anyway) whether b.
would be a win or not.

I totally agree though that the potential to leverage existing technologies
and skills is significant. So taking this a step further, if I understand
you right, you're suggesting the Nexenta approach, as it satisfies both a. and
b.  I also seem to remember reading that you're a satisfied Nexenta user(?)

Then there's also the pkgbuild system (The JDS/GNOME Team's build system)
as either a model to study or ready-made technology to employ. Pkgbuild uses
the rpmbuild standard (RPM spec files, aka build-recipes), and that
standard is common to all the RPM based distros. So it satisfies your item
a. (package build/maintenance re-use) in a big way.

(An aside regarding the Nexenta approach: I'm not sure if you're suggesting
Nexenta as a forerunner to study, or as a drop-in distro to actually be the
starting point for the Indiana distro.)

Eric