> Hi all,
> 
> At the moment I'm looking for a Sun-way of building
> Solaris packages (Like SUNW), with a proper build
> environment, but unfortunately there are too many
> ways. I already have my own customized environment,

Sun-way is SVR4 pkgadd PMS, period. I don't work for Sun and I like
to be proven wrong.

You got the point, there are too many Unix PMS. Variation is not diversity. 
Variation  increase  the cost of any engineering task.

> but I prefer to use a standard. The packaging guides
> at http://docs.sun.com/app/docs/doc/817-0406 doesnt
> provide this kind of help.
> 
> So far I've found different projects who have their
> own packaging standards:
> http://www.bpfh.net/computing/software/pkg-tools/
> http://www.sunfreeware.com/pkgadd.html
> http://www.blastwave.org/standards/pkgcreation.php
> http://www.bolthole.com/solaris/gnutopkg
> http://netbsd.org/Documentation/software/packages.html
> 
> http://www.openpkg.org

please don't miss http://www.thewrittenword.com  or 
http://en.wikibooks.org/wiki/CPAM_with_TWW

> All of these have their pros and cons.
> 
> I found a very good discussion at:
> http://www.opensolaris.org/jive/thread.jspa?messageID=
> 5520ᖐ
> 
> Let me quote some of it:
> > "I could not find a single person/could not find in
> the documentation exactly how I was supposed to go
> about adding software (such as apache 2/php5/etc, and
> I don't mean outdated versions.  - monolith"
> 
> > "I recieved a lot of "use blastwave" "use
> sunfreeware" responses, neither resource I care for
> (no offense to the projects, they just aren't my
> personal choice.) I've hand compiled/built
> everything, including all dependancies required by
> them, simply because I couldn't find a solution. This
> creates a HUGE headache anytime there is a security
> update released for ANY of the software, I have to go
> download the updated source/patches/so forth, and
> rebuild EVERYTHING one by one, making sure I get it
> all installed properly without messing up this or
> that. Imagine trying to do this by hand on 100
> systems, as you said, this is NOT the right way to go
> about things. It's painfully obvious. - monolith"
> 
> > "As far as the "accpted way" of software management
> on a Solaris
> system, well everyone has a "right" way of their own.
> -swalker"
> 
> > "If you want a quick and dirty way to create
> packages for programs that
> use "GNU" configure tools, and the like, use this
> script:
> http://www.bolthole.com/solaris/gnutopkg -swalker"
> 
> > "Sun isn't like Gentoo or FreeBSD (I believe their
> ports collection
> is similiar to Gentoo) where you get 'rolling'
> updates of
> bundled software whether the updates are security
> related or not.
> You get tested, stable versions at the time of
> shipment. -glagasse"
> 
> > "The big difference though is that the cost of
> entry for customization / 
> maintaining current status is a lot lower on Linux,
> just because you get 
> the source packages. There's a lot less effort in,
> say, changing your 
> distro's mysql-4.0.src.rpm to build
> mysql-4.1.arch.rpm than there is in 
> creating a mysql-4.1 pkg from scratch. Or what if you
> want the same 
> version that Sun shipped, but just need it compiled
> with different 
> options? That's trivial on Linux distros, not so
> trivial on Solaris.... -kaboom"
> 
> > "Note also that for the GNOME bits we do use rpm
> spec files to build and
> do ship the full build environment. Darren J Moffat"
> 
> > "OK, the .spec files will need some slight
> modification from the Linux default, but in most
> cases it is possible to write a single .spec -
> Darren"
> Are your .spec files public? Are you using OpenPKG
> specs?
> 
> > "Sunfreeware is just plain BUSTED because Steve
> Christensen doesn't really understand how to package
> software, to be more precise, he does not understand
> how to engineer software packages.

Or he doesn't have resource needed ;)

> Sun clearly states in their Application Packaging
> Developer's Guide how packages should be designed and
> what to watch out for, but apparently he either
> didn't pay attention or he just blatantly disregarded
> it. -ux-admin"
> This is still where you can get the latest built
> packages. I believe this is a really valuable
> resource, and if he didn't follow standards how
> packaging is supposed to work, then who would?
> 
> > "That's also the one big limitation of sunfreeware
> / blastwave -- no 
> concept of a "source package" to use as a starting
> point -kaboom"
> 
> -> Thats what the SUNWmysqlS package is for, it is
> intended to
> be almost equivalent to the source rpm. However rpm
> is both a build
> and package system the SVR4 package system isn't
> -darrenm.
> I can't see any references to how to use -S packages
> in the dev guide?
> 
> > Sooner or later you'll hit the `make install` part,
> which pollutes the consistency of a system. How do
> you work around that? It turns out Solaris already
> provides the facilities to do it. As it turns out, we
> can trick `make install` with some clever and
> 'creative' use of lofs(7FS), the loopback virtual
> FileSystem. (`man lofs` might do good at this
> point.)
> This really causes some problems for me such as /etc,
> because /etc/mnttab is missing, I can't even unmount
> the filesystem after I loopback-mounted it !
> 
> > "what could very easily happen is fragmentation,
> where we have trillion different OpenSolaris
> releases, and each has its own poackaging
> subsystem."
> "Hey, last night I tried to install anjuta, and it
> failed miserably!"
> "Really??? What kind of error message did `apt-get`
> give you?"
> "Oh, no, no, I was doing `emerge anjuta`, and it
> worked fine on bonnie but on clyde I'm running
> OpenSolaris with `rpm` and when I did `rpm --rebuild`
> it failed miserably... and tomorrow I have to install
> Apache + mod_xslt2 on all the 25 machines at work,
> except all of them are running OpenSolaris with a
> different software packaging system..." -uxadmin
> 
> What's stopping Sun from replacing the -pkg Format
> with for example RPM? OpenSolaris will grow in the
> next few years. Sure the old package standards could
> work... and why replacing something that works? Isn't
> it time to standardize, why not rebuild everything
> from scratch?? Clearly there are problems with Sun
> PKG, or else there wouldn't be that many side
> projects on this.
> 
> The best solution to all of this for now is:
> http://pkgbuild.sourceforge.net/. It uses the rpm
> .spec files to build and configure from source, and
> also creates a PKG. If everyone would use this,
> there's no need to read the packaging manuals,
> because SUN has supplied a standard, and it's all
> taken care of inside the pkgbuild application. Even
> the build environment is standard similar to RPM
> structure, "BUILD, PKGMAPS, PKGS, SOURCES, SPECS,
> SPKGS". One big advantage is that [b]far more people
> know how to use Linux RPM for building and
> packaging[/b]. If OpenSolaris would use it, I'm sure
> people would be interested in moving from Linux to
> OpenSolaris. In the long run, I believe the SVR4
> packages are old you really need to think about
> replacing it.

I vote with my two hands to but in reality is that I can't.

if OpenSolaris change its SVR4  PMS then I believe it just shut  the door to IT 
center and become a household hobby OS. I will change this view if Solaris (not 
OpenSolaris) switch its SVR4 PMS. but hen that time come, I will call in Sun 
Reps to beat them up if Sun don't provide me a SVR4 to other PMS transistion 
solution. 

> > "Out of curiosity, did you work with any of these
> alternative packaging systems in production? You
> know, this already exists on Solaris and has existed
> on UNIX for the past 30 years. -uxadmin"
> Time for change?

Improvement ? yes. Change to other PMS ? no.


> What we really need is a Wiki and a forum like this
> to start with. [b]Bring all the packagers, engineers
> together and let them discuss the problems,
> standards, etc etc.... ![/b]

How about here ?
http://en.wikibooks.org/wiki/OpenSolaris
or http://en.wikibooks.org/wiki/CPAM_with_TWW/References_Manual

Don't like the content  ? modify it. it is a wiki. anybody can contribute. not 
just me.

> Start a contest or something. Setup an organization
> with representatives from all these projects, let
> people (including Sun employees) write about the pros
> and cons of SVR4, and why to keep or replace it! From
> there someone should use the output of this to create
> a [b]distribution[/b] built with this new standard.

> 
> Right now, we really need a Blueprint on packaging
> (especially Open Source applications like
> Apache/MySQL, OpenSSL, OpenSSH, BIND, Sendmail etc),
> the SUN way! Lofimounting, spec-files and all this.
> 
> Note that I'm not against Sun SVR4 PKG, I already
> have my own customized environment and it works...
> But not everyone does! Monolith probably had got a
> good headache reading through the application
> packaging developers guide, and ended up using
> Blastwave anyway. If he only knew about pkg-tools, he
> could have built his Sun packages with a public
> archive of Solaris-RPM specs.
> 
> Hope to start a discussion here.

discussion had happened in many other threads. 
Don't know when the dust will settle.

tj
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to