[kde-solaris] KDE 3.1.4 binary packageing

[Rolf Sponsel]

Please read my comments in-line.

Best Regards

/ Rolf

Lars Tunkrans wrote:
> 
> steleman at nyc.rr.com wrote:
> > I have addressed the question about naming
> > conventions before, but i will address it again.
> >
> > Packaging Solaris packages with the SUNW prefix is
> > the naming convention recommended by Sun
> > Microsystems in their AnswerBook collection
> > ["Building Packages"].
> >
> 
>    Allright if thats what they propose.

Well this IS a novelty for me :-O

I guess Lars and I must have read an "export" version
of Sun's guidelines ;-) Because I couldn't agree more
with what Lars wrote about the usage and origin of the
SUNW prefix. I am certain that that is my understanding
of this issue since many, many years back in time.

Consider this!? Why require to use a prefix like 'SUNW'
at all if NOT TO distinguish different package origins?

Particularly considering that the recommended/significant
length of package names are nine (9) characters, which
leaves only 5 chars for naming your package. Now consider
two parties providing an OpenLDAP package. What would be
the obvious name of their respective packages?

No offence, but I think you'll have present some proof
here to convince me before I can accept this statement.
Sorry :-(

I am aware though that, at least older man pages, contain
a lot of Sun internal packaging information.

I also agree with Lars when it comes to appropriate
way to package packages to be delivered. Sorry again.

> 
> > Building the packages with pkgproto and pkgmk is
> > also the method recommended by Sun Microsystems in
> > the same publication.
> >
> > There is no connection (that i am aware of) between
> > KDE e.V, my KDE 3.1.4 packages for SunOS 5.8, and
> > NASDAQ.
> >
> > Indeed, these packages will only be useful on a
> > SPARC/SunOS system. Given the fact that they contain
> > binary code which would only run on SPARC/SunOS
> > system, i do not see a problem here -- but maybe i
> > am missing something.
> >
> > I have successfully and correctly bunzip'ed and
> > untarred these packages on my Linux Intel laptop
> >
> 
>    O.k  I'll try to explain better ...
> 
>    Within the Unix sVr4  system designed by AT&T in the
>    end of the 1980's, Two methods of Package distribution
>    was designed.  "filesystem format"  and " datastream format"
> 
>    pkgmk(1) produces  filesystem format. It creates a separate
>    directory tree consisting of all the files in the package.
> 
>    In 1989  the main program distribution format was tape.
>    AT&T  wanted a program distribution system that would install
>    directly  from tape. So what we did in those days was:
> 
>       pkgadd -d /dev/rmt/0  { packagename }
> 
>    This ofcourse does not work if you have a directory structre
>    on the tape. It does work if the tape contained the
>    DaTaStReAm format.
> 
>    the Utility program  pkgtrans(1)   converts a package
>    from filesystem format into datastream format.
>    The datastream format is a singel large file.
> 
>    This resulting file is directly installable. It does not
>    need to be "unpacked"  the pkgadd utility knows within itself
>    how to unpack the datastream format.
> 
>    so basically one does
> 
>    pkgtrans  -s  /space/src  /space/obj/package_name.pkg package_name
> 
>    /space/src is the parent directory to where the package_dir resides,
>    /space/obj/package_name.pkg  is the output file
>    package_name  is obvioulsly the name of the package and the source directory.
> 
>    Then one would compress the  /space/obj/package_name.pkg file by some means.
>    and send it to the distribution ftp server.
> 
>    After an installer downloads the package file and decompresses it , he/she  can just
>    do a :
> 
>     pkgadd -d ./package_name.pkg
> 
>    The whole business of untaring the tarball becomes unnessesary.
> 
>     //Lars
> 
> ========================================================
> Lars Tunkrans
> --------------------------------------------------------

-- 
----
------
--------

Rolf Sponsel

___________________________________________e_n_d___o_f___m_e_s_s_a_g_e_