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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-1.0.0.0.rpm contains, one jar file named PWEL-EJB.jar. the rpm installs the jar file to $JBOSS_HOME/server/default/deploy/.

2) package pwel-ejb-2.0.0.0.rpm 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-1.0.0.0.rpm.

what is the best practice or approach to employ if i want to UNINSTALL the jar file from package pwel-ejb-2.0.0.0.rpm and "fall back" to using the jar file installed from package pwel-ejb-1.0.0.0.rpm?
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.

Florian



_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list


[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux