how do you "fall back" to a previous file in a previous package

FlorianFesti ffesti at
Wed Mar 2 10:41:03 UTC 2011

On 03/01/2011 09:39 PM, mark meyer wrote:
> hello all,
> i am just getting in to the process of redefining our build / 
> packaging environment to support rpm distribution.  to date - we have 
> adopted an approach where by we distribute a .tar file and simply 
> over-lay the files system.
> i have been reading the documentation mentioned on the list in a prior 
> post - but have a specific question:
> example use case:
> 1) package pwel-ejb- contains, one jar file named 
> PWEL-EJB.jar.  the rpm installs the jar file to 
> $JBOSS_HOME/server/default/deploy/.
> 2) package pwel-ejb- contains one jar file named 
> PWEL-EJB.jar.  the rpm installs the jar file to 
> $JBOSS_HOME/server/default/deploy/ in effect over-laying the jar file 
> from package pwel-ejb-
> what is the best practice or approach to employ if i want to UNINSTALL 
> the jar file from package pwel-ejb- and "fall back" to 
> using the jar file installed from package pwel-ejb-
Well, the model RPM uses is - as far as I understand - a bit different 
from what most web applications do. RPM puts files to a fixed place on 
the file system. If $JBOSS_HOME is a dynamically set variable RPM won't 
be that good in dealing with it. If it is something you define once for 
all users of the RPM you should be fine.

Same with the version numbers. RPM packages with the same name are 
supposed to be one line of updates. So if you have foo-1.0 installed it 
is going to be updated with foo-2.0 even automatically (if you configure 
you system accordingly). If you want it to be a real choice you 
typically include the major version into the package name:

foo1-1.0.0 that is updated to foo1-1.0.1
and foo2-2.0.0 that is updated to foo2-2.0.1 or foo2-2.1.0

If foo1 and foo2 contain the same files you should set a conflict 
between them.

There are also couple of other naming schemes.

foo for the newest major version and foo-compat if there is just one 
older version that is relevant
or foo for the newest (3.x in this example) and foo2 and foo1 for the 
older branches. It is also possible to use more than just the major 
number within the name.


More information about the Rpm-list mailing list