Re: gensrclist call to rpm

On Thu, 5 Aug 2004 09:05:29 +0300 (EEST), Panu Matilainen
<[email protected]> wrote:
> On Wed, 4 Aug 2004, Aamer Akhter wrote:
> >
> > I agree. The environment I'm building for does not have a predictable
> > place for rpmrc. This is partly due to the fact that I'm using atp-rpm
> > not for os distribution, but only as an add-on to an existing os
> > (solaris and linux). The other thing is that, almost always the
> > 'distribution' (again it's not an os, it's an environment build ontop
> > of solaris and linux) will be installed in a network mount.
> >
> > So the short of it is that the location of rpmrc is not predictable at
> > compile time. Another option is to build a local rpm everytime an
> > install is done. This is probably not going to work well, as on
> > solaris there isn't a common environment (even gcc, isn't there
> > sometimes).
> 
> Ouch, sounds like a serious maintenance nightmare :-/ 

lol. agreed. for these kinds of things a linux install, regardless of
distribution starts looking very attractive it's much more
predictable.

> Not knowing the
> environment it's hard to make suggestions but wouldn't it be easier to
> build rpm with --sysconfdif=/etc (or such) so that no matter where the rpm
> executable lives, rpmrc can always be found in a predicable place, even if
> that means copying (or symlinking) rpmrc into place on each host?

that's actually not a bad idea. :-)
reality is that the users installing this layered environment will not
always have root/sudo access. additionally, the strategy has been that
any files realted to the environmnet should be local to the directory
tree installed. otherwise there'll be other probs down the road wrt to
portability etc.

i do like your patch below, it seems to give better control. Have you
considered providing the patch to the rpm guys? I'm sure other people
may find it usefull also.

> 
> The attached patch adds a new configuration setting RPM::RCFile so you can
> use 'apt-get -o RPM::RCFile="/where/ever/rpmrc" install foo' BUT this
> doesn't fix the gen*list case, since although you could set RPM::RCFile in
> apt.conf I guess that's not in any predictable place either(?) 

but thankfully, there's an env variable to control the location of apt.conf.

> and
> gen*list programs don't allow passing in arbitrary config options.
> Anyway I suppose something like this patch should perhaps be included in
> apt nevertheless.
> 
> >
> > I suppose a good way of handling this would be to patch the rpm source
> > so that it looks for rpmrc based on an environment variable (that much
> > we (our org) can agree on). Of course this would be patch local to our
> > org though.
> >
> > It looks like the patch would be in rpmReadConfigFiles(). I guess I
> > need to brush up my C to get that done ;-)
> 
> Something like this perhaps ... patch is against rpm 4.3.1 but probably
> applies to 4.1 as well. Mind you it's completely untested :)
> 
> --- rpm-4.3.1/lib/rpmrc.c.env   2004-08-05 08:55:12.633345431 +0300
> +++ rpm-4.3.1/lib/rpmrc.c       2004-08-05 09:00:01.438388819 +0300
> @@ -1735,8 +1735,12 @@
>         defaultsInitialized = 1;
>      }
> 
> -    if (rcfiles == NULL)
> -       rcfiles = defrcfiles;
> +    if (rcfiles == NULL) {
> +       if (getenv("RPM_RPMRC") == NULL)
> +               rcfiles = defrcfiles;
> +       else
> +               rcfiles = getenv("RPM_RPMRC");
> +    }
> 

cool. i looked at this very quickly before getting on a plane, been in
transit all day, and the 4.1 code is the same. i'll play around with
this and get back to the mailing list with the results. i should
mention that the above code does away with pulling in the users rpmrc
file (which is represented in defrcfiles). maybe the thing to do is to
do a prependto defrcfiles...


again, thank-you very much for working on apt-rpm

>      /* Read each file in rcfiles. */
>      rc = 0;
> 
>         - Panu -
> 
> 




-- 
Aamer Akhter / [email protected]