Nexenta Repository Policy: 'main'

Draft 0.7 - work in progress

It is time to analyze what is happening with Debian-based distributions and why distributions so spread out like mushrooms after a warm autumn rain. The common denominator still remains, however, heavily changed. Package built for Debian still might work in Ubuntu, but this is not guaranteed, many interdependencies changed sporadically and not always propagated into original Debian base.

Nexenta Core Platform opens unique opportunity for future distribution builders and potential software vendors, that is common Nexenta Core ground. Needless to say that we have to be thankful to OpenSolaris binary API stability and dedication to not break things and preserve stability during even highly intrusive feature integrations.

Nexenta Operating System build on top of Debian foundation. Debian uses set of remote APT repositories as a storage for general purpose or specialized applications. Debian Policy defines repositories: 'main', 'contrib' and non-free.

'main' repository includes required and optional applications which are developed and tested by the community. This is usually known as "supported" repository.

Nexenta takes minimalistic yet flexible approach by stripping original 'main' repository into smaller subset of commonly used libraries and console-only applications.

Which upstream repository to use for 'main'

Ubuntu LTS releases, such as Dapper and upcoming Hardy. However, backporting is allowed

What must be included as a part of 'main'

sunw core packages ('sunwcakr', 'sunwkvm', 'sunwcsr', 'sunwckr', 'sunwcnetr', 'sunwcsu', 'sunwcsd', 'sunwcsl'), sunw* ON packages and sunw* integrated packages such as COMSTAR/NWS/etc
debian core packages ('coreutils', 'sed', 'awk', etc) and scripts
common libraries ('libruby', 'libdbus', etc) and ground desktop base Xorg
commonly used languages ('perl', 'python', 'ruby', etc) and set of libraries for them
commonly used console applications ('subversion', 'vim', etc)
commonly used system and application services ('apache', 'mysql', 'postresql', etc)

What must NOT be included as a part of 'main'

GUI application, instead specialized repository needs to be created, and supported by their owners. Example: XFCE applications and session libraries must be provided in external repository, by another community which will generate its own ISO image and provide required support and upgrades
GUI libraries which are specialized and not required by any of existing repositories. If repository A requires GUI library from repository B, library could be considered for inclusion into 'main'
Console applications which are rarely used or obsolete. Such existing application could be considered for removal
Libraries which are not used by any existing application in 'main' or other repositories. Such existing libraries could be considered for removal
Languages which are known obsolete. Such existing languages could be considered for removal

How Ubuntu's package version converted to Nexenta

NexentaOS sits "on-top" of Ubuntu user land. Without special care to the package version, complex inter-package dependencies will break. To avoid breakages dpkg/apt/devscripts/etc modified to understand notation of ubuntu# and nexenta# distribution versions. Internally dpkg/apt always re-placing "nexenta" with "ubuntu" so original Debian dependency logic _always_ preserved and no need in debian/control modification. Example of proper version conversion: 4.3.4-24ubuntu2 => 4.3.4-24nexenta2.

Where Nexenta patches needs to be sent

NexentaOS patch flow direction: Nexenta => Ubuntu => Debian => Original

If time permits, generic OpenSolaris porting fix needs to be sent directly to package upstream. Example: xorg fix for sparc64 architecture needs to be sent to www.freedesktop.org
While sending patch to Debian/Ubuntu maintainers, it's important to explain what the patch is for and why it's relevant in Debian/Ubuntu
A patch needs to be send to corresponding Debian maintainer (find out via debian/control) unless it was modified by Ubuntu