RPM Community Forums

Mailing List Message of <rpm-users>

Re: Is rpm5 going to attempt to end the fight between package formats.

From: Jeff Johnson <n3npq@mac.com>
Date: Thu 21 Jun 2007 - 19:40:52 CEST
Message-Id: <A1FBF9A3-34F1-4FA5-BB9D-C52B05759318@mac.com>

On Jun 18, 2007, at 7:53 PM, Russell Coker wrote:

> On Monday 18 June 2007 11:09, Jeff Johnson <n3npq@mac.com> wrote:
>>> Silent install options.  Last time I looked at rpm it installed but
>>> did not configure other than defaults.  rpm -i package.rpm  
>>> package.sil
>>>  Would be a idea. sil being a simple archive containing the changed
>>> files and script for special alterations.  Of course package would
>>> have to support creating this.
> In that case you want to use some of the similar concepts to  
> Debconf in terms
> of external storage of configuration options and the ability to  
> extract
> configuration options from a running system as part of a clone  
> procedure.
> Debconf that also supports file diffs would be a good thing.  To do  
> this in a
> complete manner you would want to be able to support arbitrary file  
> diffs
> that are supplied by the sys-admin for any file on the system (the  
> check could be used to prompt the sys-admin for which files they  
> may want to
> supply diff files for) and also be able to automatically generate  
> diffs for
> files under /etc.  /etc on my laptop is 39M according to du and 5M  
> when
> in .tar.gz form.  With today's hard drive sizes it would be trivial  
> to keep a
> backup of all those files for the purpose of running diff.  Also if a
> sub-directory of /etc is owned by the package then any new files  
> could be
> included in the diff.

Dual installing virgin copies of files in *.rpm packages marked with % 
config on
an alternative shadow tree, and wiring up
     rpm -qc --diff PACKAGE
to show local modifications wrto distribute versions, has been on my  
rpm todo
list for some time.

Adding the additional feature of substituting per-system values within
config files is certainly feasible as well. OTOH, changing rpm's  
paradigm to accomodate the substitution is the rate limiting step,  
and will
likely take years to accomplish.

The intrinsic design difference between dpkg and rpm, however, is  
a dialogue is permitted with the person installing a package. dpkg  
has an
explicit configuration stage with a end-user dialogue while rpm does  

> For the implementation you don't want to do it the way Debconf was
> implemented.  Having a shell script source another script that then  
> re-exec's
> it with stdout/stdin changed causes many problems.  stdin/stdout/ 
> stderr
> should be strictly used for tasks that are conceptually similar to  
> their
> original design when it comes to complex programs.  Probably the  
> best thing
> to do would be to have a server for the configuration database that  
> runs on a
> Unix domain socket and is spawned by rpm.  Rpm could then instruct  
> the server
> to exit after it has finished it's operations (maybe have the  
> server exit
> after the last client connection closes and have rpm keep a  
> connection open).
> File diffs aren't adequate, we also need configuration options for the
> postinst script (or similar).  Think about passwords in databases  
> and other
> things that can't sanely be handled by file diffs.  I guess you  
> could just
> write a bunch of shell scripts for these things, but I think it  
> would be best
> if cooperative package maintainers would write scripts for them.

Noted, thanks for the detailed information.

73 de Jeff
Received on Thu Jun 21 19:41:40 2007
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.