> Hi,
>
> TJ Yang wrote:
> > I read albertw's blog but I failed to understand
> how to use Solaris'
> > patch management system to be a modern PMS for
> OpenSoalris.
> >
> >
> >> I would advocate the use of patches for updating
> packages. But I would
> >> be very >interested in seeing the things that
> people don't like about
> >> patches and patch >management and what
> enhancements folks think should
> >> be added.
> >
>
> > To me a modern PMS need to have following
> features.
> > 1. support software build
> > 1.1 automate the process of software building.
>
> This is something that I hope would be documented by
> the patch and package
> utilities team when they get to opensourcing their
> tools. Maintaining a
> software gate is a complex task and there is a lot of
> process to consider
> as well as tools. However the process can be
> sufficiently automated to
> allow an engineer to easily create a patch if needed
> (eg IDR's).
>
> SVR4 patches and packages support the use of scripts
> withing patches and
> packages to achieve certain behaviors. Specific
> editing of config files
> being one example. Obviously if you are in a
> situation where you need to
> write such scripts your process will require manual
> intervention
I am hoping building software on Solaris could be like doing software building
on FreeBSD. It has a automated build system to let us type "make world" to auto
build all the packages.
> > 1.2 auto build another application if depended
> by current one.
>
> That is not so straight forward. For example a libc
> change does not require
> you to redeliver everything even though pretty much
> everything depends on
> it. Perhaps some patch creators or gatekeepers on the
> list can elaborate on
> this.
for example like buiding autoconf-2.5.9, TWW's HPMS system has
all the dependency specified when bulidng autoconf-2.5.9.
<snip>
program name="autoconf" version="2.59" revision="4">
<build-name>${SB_PROG_NAME}-${SB_PROG_VER}</build-name>
<install-name>${SB_PROG_NAME}25</install-name>
-
<sources>
<source checksum="d4d45eaa1769d45e59dcb131a4af17a0" checksum-type="md5"
size="1236359" path="src/autoconf-2.59.tar.gz"/>
<patch checksum="4e1517a196a1e8fb9da1ee3fa10ecdee" checksum-type="md5"
size="29911" path="src/autoconf-2.59.patch"/>
</sources>
-
<program name="autoconf" version="2.59" revision="4">
<build-name>${SB_PROG_NAME}-${SB_PROG_VER}</build-name>
<install-name>${SB_PROG_NAME}25</install-name>
-
<sources>
<source checksum="d4d45eaa1769d45e59dcb131a4af17a0" checksum-type="md5"
size="1236359" path="src/autoconf-2.59.tar.gz"/>
<patch checksum="4e1517a196a1e8fb9da1ee3fa10ecdee" checksum-type="md5"
size="29911" path="src/autoconf-2.59.patch"/>
</sources>
<dependencies>
<depend program="gawk" install-name="gawk31"
add-path="prepend">v>=3.1.4</depend>
<depend program="help2man" var="HELP2MAN">v>=1.29</depend>
<depend program="sed" install-name="gsed40" add-path="prepend">v>=4.0.9</depend>
<depend program="m4" var="M4">v>=1.4</depend>
<depend program="perl" var="PERL">v==5.8.2</depend>
<depend program="texinfo" add-path="prepend">v==4.7</depend>
</dependencies>
<snip>
details at
ftp://support.thewrittenword.com/dists/7.0/src/autoconf-2.59/sb-db.xml
An idea Solaris build system(FreeBSD can) should be able to take the "make
autoconf-2.59" command and build help2man,sed,m4,perl and texinfo before it
start to build autoconf-2.59.
>
> > 2. support packaging(turn binaries,doc into a
> special format for installation).
>
> Already provided by pkgmk(1). Our internal tools to
> create patches have not
> been opened yet.
>
> > 3. support application depot
> > a local or centralize server to accept and
> deploy packages.
>
> Well at the simplest level you can put all your
> packages and patches onto
> an NFS server and a cronjob to update. Or you can use
> the pkg-get approach
> to deployment. For patches consider how smpatch and
> the Sun Update
> Connection Manager do things. Using SVR4 packages and
> patches does not
> force you into a particular "application depot"
> method, you are free to
> choose whatever you wish for your opensolaris
> distribution. In fact by
> using SVR4 patches and packages you will find it
> easier to leverage
> existing higher level applications for your purposes
> (eg. your HPMS TWW
> system).
As a package user, I want to be able to find out existing
installed application. And also I want to understand what applicaton
are avaible in a central apps depot server. HP-UX's SD-UX is a
another example that has this packages query feature.
PS. I am merely an user TWW HPMS. We dropped our own HPMS system in favor of
TWW one becuase it is better in all aspect compare to our homegrown one at work.
>
> Having said that there is room for RFE's to the
> package and patch utilities.
>
> > 4. support application management activities.
> > 4.1 install : better yet, support auto install
> if dependency appear.
>
> pkgadd and patchadd handle install. patchadd in
> solaris 10 has the ability
> to solve patch dependencies when give a list of
> patches so they are
> installed in the right order (checking of
> SUNW_REQUIRES). pkg-get is an
> example of how the architecture can be used to
> automatically install
> dependencies.
Exactly, I like to see pkg-get's auto install feature in future Solaris PMS.
> > 4.2 remove: auto remove depended application if
> need to.
>
> So if package or patch X requires Y, then when you go
> to remove Y, X is
> also removed? This is an existing RFE I believe for
> pkgrm. smpatch does
> this for patches (I think) and perhaps patchrm should
> have this ability also.
To remove or not, it is left to sysadmin. but the pkgrm should
has ability to provide this option.
>
> > 4.3 query : provide local installed application
> and aviable apps on apps depot.
>
> I don't understand your description here. Each system
> will have its own
> record of what is installed (/var/sadm...). Based on
> this it would be
> possible to query your 'depot' to look for changes
> and then choose to
> install those changes. 'smpatch analyze' is a good
> example of this for
> patches. 'pkg-get -c' is an example of how to achieve
> this with packages.
To be specific and use pkginfo as example.
pkginfo can only list out the local installed package from /var/sadm/* package
reqistry directory. but it can't provide me a list of avaiable packages on apps
depot.
>
> > 4.4 update: auto remove the existing app or
> insert the deltas.
>
> This is similar to a combination of install and
> query. Once you have a
> given set of packages and patches installed it is
> possible to determine
> from a given list of patches which will install on
> the system ('smpatch
> analyze' and 'patchadd -M <directory of patches>' for
> example).
>
> > Would you please advise me how Solaris patch
> management system support
> > above requirements ?
>
> Your questions come in two flavors. Creation of
> patches/packages and higher
> level package management.
To me a moden PMS (like RPM,openpkg) should address both package creation and
management.
<snip>
> For the reasons there I think it is in everyones best
> interest to use the
> existing package architecture in opensolaris based
> distributions.
I agree. opensolaris should use same PMS commercial Solaris use.
If Solaris switch to other PMS, opensoalris should follow also.
>
> Any distribution that chooses this format will then
> automatically be able
> to leverage the various higher level package
> management tools that have
> been discussed here before to update their system.
>
> If a consensus develops among the distributions to go
> with a particular
> high level management system then thats great. But
> its a separate
> discussion from whether to use the SVR4 package
> architecture.
Personally, I like to see the arguments of why not to use SVR4 package
architecture.
Please put your comments here at
http://en.wikibooks.org/wiki/OpenSolaris/Reference_Manual#Adopt_existing_better_PMS
Another PS, this opensolaris wiki is not mine, it is in PD. await your
contribution.
tj
>
> Cheers,
> ~Al
> --
> Albert White - Patch System Test - SUN Ireland
> _______________________________________________
> opensolaris-discuss mailing list
> [email protected]
>
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
