Intro to Nexenta with an upstream distribution that is primarily Ubuntu

TODO: Write introduction to the concept of importing pre-built packages

Steps to import a package from an upstream source

TODO: 

  • fill in stuff below 
a little prose in the beginning to ease someone into the process

1. (One time) Generate GPG key + have signed by Nexenta Core (include email address here)

  • (build instructions to do this part)

2. Add the correct sources list + apt-get update

  • (Ubuntu dapper sources...) (apt-get update...)

3. Get the latest source package available: 

    % apt-get source package
  • (show example output and explain the unpacked sources)

4. Update the .changes file 

    % cd package-version
    % dch -i (from devscripts package)
  • (see version information below) (change the name+email of the maintainer to that of your GPG key)

5. build the package 

    % fakeroot dpkg-buildpackage
  • (You may need to install build dependencies to do this, "apt-get build-dep" sometimes does the trick) (sometimes build versions need to be modified to fit available versions of packages)

6. test the package 

    % cd ../
    % sudo debi package-version.changes
  • (explain falling points here)

7. upload the package 

    % dput package-version.changes
  • (show+explain output) (The ftp incoming directory is watched for new files. Once new files exist, the ftp master will accept/reject the package.)

Steps to update a package from a Nexenta source

  • Two ways of making changes
    1. maintain the package yourself b. submit a patch to the current maintainer
  • Example of importing a package (from Debian, from Ubuntu) + (link to MM's screencast)

Underpinnings of why these rules are in place

  • Package source versions
  • Nexenta version should trump upstream version
  • Generated package dependencies that break otherwise:

    Operation

    Example Test

    <

    0.9.2.28nexenta1 < 0.9.2.28ubuntu1.1

    <=

    0.9.2.28nexenta1 <= 0.9.2.28ubuntu2

    ==

    0.9.2.28nexenta1 == 0.9.2.28ubuntu1

    =>

    0.9.2.28nexenta1 => 0.9.2.28ubuntu1

    >

    0.9.2.28nexenta2 > 0.9.2.28ubuntu1

Implementation Details

Convention to compare package versions

  • Any tools used for Nexenta package version comparison *must* use "dpkg --compare-versions" for the version comparison. An example of this comparison: 

  # dpkg --compare-versions 0.9.2.28nexenta1 eq 0.9.2.28ubuntu1
  # echo $?
  0
  # dpkg --compare-versions 0.9.2.28nexenta2 gt 0.9.2.28ubuntu1
  # echo $?
  0

Some tools that do not yet implement the convention

  • Tool

    Reason

    apt-show-source

    uses internal comparison that does not follow convention

Making revisions to your package

For a screencast on modifying packages see Martin Man's Weblog and look for "Patching OpenSolaris the Debian Way".

Unanswered questions

  • Once package is installed, check against source versions, why do we need nexenta(N) appended to the version?
  • Why does the internal debian/control need version changes? What are the rules?
  • How do I create a package for Nexenta only?