[Rpm-maint] Re: Rpm-maint Digest, Vol 4, Issue 1

[JP Vossen]

> Date: Wed, 28 Feb 2007 17:28:26 -0500
> From: "James Olin Oden" <james.oden at gmail.com>
> Subject: Re: [Rpm-maint] RPM supports variable group name ?
> To: Sangeeta.Varma at sun.com
> Cc: rpm-maint at lists.rpm.org
> 
> On 2/28/07, Sangeeta Varma <Sangeeta.Varma at sun.com> wrote:
>> Hello,
>>
>> I have an urgent requirement to be able to deliver a binary in an RPM
>> with an unknown group name, at the rpm build time.  The Group name will
>> be known only at install time.
>>
>> On solaris with packages, its possible to support this using the
>> "request" scripts to get input from the package installer and a
>> variable for the group name in the prototype file.
>>
>> Can anyone let me know if something like this is doable with RPMs ? I
>> haven't found any information on this. Any pointers will be much
>> appreciated.
>>
>> Please cc me onthe response as I am not yet subscribed to this alias.


> I'm very familiar with this feature of solaris packaging and the short
> answer is no.
> 
> RPM has never supported a way to query the user for anything.  The on
> going mantra is that rpms should be installed non-interactively and
> that giving some interactive capability would break automated
> installers.  This of course is not true if
> done in a similar way to Solarises package manager.
> 
> Essentially the Solaris package manager allows setup a package to ask
> custom questions, the answer of which can be supplied by an
> administratively supplied config file.  This could be done in rpm
> also.  You would need to take it one step further such that it would
> not break an automated installer, and mandetorily enforce that default
> answers be supplied in the spec, such that any querying could be
> reasonably turned off by an installer while yet still allowing for the
> use of the package admin files.  So that is one way that this can be
> achieved.
> 
> Another way that one could achieve this is via the use of install time
> expansion of macros.  This actually can be used to solve many problems
> in rpm; in particular though it would give the effect of the solaris
> package admin files without ever seeing
> a query.  One could even check to see if a particular macro was expanded or not
> and die if it was not.
> 
> Either of these approaches are completely new features to rpm (though
> the later is more easily achieved).  This means that someone would
> have to code these features, and it would take a good while for them
> to make it to the mainstream distributions.  Also, you would need to
> find someone interested in doing this work, or you would have to do it
> yourself.
> 
> So you can see why I said the simple answer is no.   With some devoted
> cycles though you can reach the harder to achieve yes.

OK, it's been a while since I really worked on a spec file, so maybe I 
am missing something obvious.  But why can you simply write a post 
install script to:
	1) ask for (and validate?) the group name
	2) create the new group
	3) chgrp the relevant files to the correct group

Yes, I know that this breaks the "non-interactivity" guideline [1], and 
that to some extent it may require some duplicate code (e.g., lists of 
files for the RPM to install, then the script to later chgrp).  So it's 
quick, dirty and non-standard, but I don't see why it wouldn't also 
solve this user's problem.

Having said all that, I forget the exact way to make this happen 
(%postinst?), but I'm sure if the idea is actually sound someone else 
can provide pointers to the OP.

What am I missing?

Later,
JP

[1] Not to get too far off the topic, or to start flame war, but after 
experiencing Debian's "debconf" features, I am not a big of the RPM 
"non-interactivity" guideline.  I understand the reasons and agree, but 
Debian users can have their cake and eat it to.  Normal interactive 
installs can ask question, which results in a WORKING package 
out-of-the-box, while the silent RPM often needs manual editing to get 
it to work right.  Bad trade-off, IMO.  Meanwhile debs can also be 
installed non-interactively, at the risk of not working out-of-the-box 
(just like RPMs).  Having stuff Just Work is a Good Thing...  :-)
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|        jp{at}jpsdomain{dot}org
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
Microsoft has single-handedly nullified Moore's Law.
Innate design flaws of Windows make a personal firewall, anti-virus
and anti-malware software mandatory. The resulting software arms race
has effectively flattened Moore's Law on hardware running Windows.