Re: Package Manager

[thomas.raddatz@xxxxxx]

Scott,

I absolutely agree with you that a central repository is required to run a
package manager. I never had the idea to scan every program and service
program for a COPYRIGHT string in order to get the package information. All
I did so far is to try to find a practical way to get the information.

What I actually have in mind is a repository made of some database files.
Whenever an application gets installed on a System i it may (or may not)
try to register itself at the repository. That may be done by executing a
known package manager command or somehow else. I did not thoroughly think
about whether it may be possible to pass all information with the REGISTER
command or just let the package manager know the program or service program
that contains the information. For now I think the latter one is better
because then it may be possible to manually execute the REGISTER command
(by a user) in case the package manager was not yet present at the time an
application has been installed.

For now I prefer to use the COPYRIGHT information rather than using an IFS
stream file because then the application (at least that specific object)
and the package information are tight together. That is not the case when
using a stream file. If you want to use a stream file you also need a way
to verify that a stream file and an application matches to ensure
integrity. I assume that most of the PC application use file. I also assume
that a file might be more flexible than the COPYRIGHT information together
with one or more "PkgMgr_getProperties" procedures. But I still love the
idea to have the package manager information inside a program or service
program and not inside an IFS folder which could be manipulated by anyone
(which of course may also be an advantage).

Thomas.


> Thomas,
>
> Once again, I want to point out that you need some sort of central
> repository of packages on the system.  At least, if you want the package
> manager to be able to present a subfile with all of the packages on the
> system, you're going to need somewhere for it to find out what all of
> those packages are.
>
> I hardly think it's practical to scan every program and service program
> on the system for a COPYRIGHT string.
>
> My suggestion, in a previous message, was to have an IFS directory where
> you place all of the package info, including the version, site to check
> for updates, etc.  Each time you install a package, it writes it's own
> information into that IFS directory.  When you want to look for updates,
> the package manager reads all of the files in that directory to
> determine what you have, then checks teh corresponding web sites for
> updates, and puts the results in a subfile (or web page or whatever).
>
> Seems simple.  Why do you want to use an exported subprocedure or the
> copyright information for something like this?  Seems to make it more
> complicated, and still leaves us without any information about the web
> site, etc.
>
>
> Thomas Raddatz wrote:
> > Hi folks,
> >
> > I thought it was a good idea to rather start a new thread about a
> > "Package Manager" than continuing the discussion in the "post" thread.
> >
> > @Mike:
> >
> > I played a bit around with the idea of a package manager and wrote a
> > bunch of procedures to retrieve package manager related information
from
> > a given service program. While playing around I had the idea to use the

> > copyright information to provide package manager related information.
> > Doing it this way eliminates the need for calling a generic procedure
at
> > a first step. Here is the copyright information I used:
> >
> >    V1.9 - 29.01.2009 - IFS file and directory procedures
> >    PKGMGR(version=1.9; date=29.01.2009; domain=de.tools400.ifs2.)
> >
> > Please notice the "PKGMGR" keyword. It is used to define attributes for

> > the package manager. In order to get the information I call a procedure

> > that uses QBNLSPGM to retrieve the copyright information, retrieve the
> > PKGMGR(...) keyword data and break it into peaces (key/value pairs).
The
> > key/value pairs are stores in a property list. Now the tricky part
> > begins. I then use the "domain" value "de.tools400.ifs2." to produce
the
> > following procedure name:
> >
> >    de.tools400.ifs2.PkgMgr_getProperties
> >
> > "PkgMgr_getProperties" is a constant that is simply added to the domain

> > name. Once that I have the procedure name I activate the service
> > programs and call the procedure to get additional properties. Calling
> > "PkgMgr_getProperties" is optional! If all properties could be defined
> > at the PKGMGR() keyword calling "PkgMgr_getProperties" is not
necessary.
> > But in case there is not enough space at the copyright information to
> > define all properties, "PkgMgr_getProperties" is an option.
> >
> > "PkgMgr_getProperties" takes no parameters and returns a string like
that:
> >
> >    'vendor=Tools/400; email=info@xxxxxxxxxx'
> >
> > The properties defined in the string are also added to the property
> > list. Because of the domain prefix (in Java they call it "package")
> > "PkgMgr_getProperties" is worldwide unique. So there should be no
> > trouble with duplicate procedure exports when linking programs or
> > service programs. I think it was Scott who mentioned that problem in a
> > previous posting.
> >
> > If a product does not have a service program I could also retrieve the
> > copyright information from a program or from a data area.
> >
> > Regards,
> >
> > Thomas.
> >
> >
> >
------------------------------------------------------------------------
> >
> > -----------------------------------------------------------------------
> > This is the FTPAPI mailing list.  To unsubscribe, please go to:
> > http://www.scottklement.com/mailman/listinfo/ftpapi
> > -----------------------------------------------------------------------
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------


--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence. Please delete if obtained in error and email confirmation to the sender.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------