4

I would like to use a rpm to build subpackages for different environments (live,testing,developer) but for the same files, so having a package called name-config-live, one called name-config-testing and one called name-config-developer and in them to have the same paths but each with the configs corresponding to the environment it's named after. as an example

let's say on all environments I have a file called /etc/name.conf and on testing I want it to contain "1", on development "2" and on live "3". Is it possible to do this in the same spec since the subpackage generation only happens last not in the order I enter it. ( and hopefully not with %post -n )

I tried using BuildRoot but it seems that's a global attribute

Sorin
  • 43
  • 4

1 Answers1

3

I don't think there's a native way; I would do a %post like you had noted.

However, I would do this (similar to something I do with an internal-only package I develop for work):

  1. Three separate files /etc/name.conf-developer, /etc/name.conf-live, etc.
  2. Have all three packages provide a virtual package, e.g. name-config
  3. Have main package require name-config
    • This will make rpm, yum, or whatever require at least one be installed in the same transaction
  4. Have all three packages conflict with each other
  5. Have each config package's %post (and possibly %verify) symlink /etc/name.conf to the proper config
    • This also helps show the user what is happening

Cons:

  1. It's a little hackish
  2. rpm --whatprovides /etc/name.conf will say it is not owned by any package
Aaron D. Marasco
  • 6,506
  • 3
  • 26
  • 39
  • That is exactly what I am doing now. I'm thinking to create a list of files and append the evn to the end for each one ( /etc/name.conf.live, /etc/name.conf.devel ) and using %post just to rename them to /etc/name.conf, while they live and devel packages are conflicting so I won't be able to install all of them at the same time. – Sorin Oct 03 '12 at 08:29
  • 3
    Then `rpm -V` will say that the now-renamed file is missing, and it still wouldn't help the `--whatprovides` issue I mentioned above. At least with the symlink, a smart enough user can see that it points to a file that *is* in the RPM database. – Aaron D. Marasco Oct 03 '12 at 22:56