On 03/02/2011 09:51 PM, mark meyer wrote:
are you saying that i cannot use my existing version number scheme?
right now our ant / java build environment supports this kind of
versioning scheme:
if i were to tag and build the code right now i would produce this:
PWEL-EJB-2.5.0.9/
which would build PWEL-EJB.jar
i was hoping to package this jar file in to a single rpm named:
pwel-ejb-2.5.0.9.rpm
is this a reasonable approach ?
Well it depends. Packages with the same name are seen as one line of
updates. Typically users should not decide what exact version they want
but only when to upgrade to the next version (and do additional testing
if this is necessary). Reason for this is to make sure you do not get
stuck on an old version that has security or other problems without
noticing. You as a provider of the package are responsible to make
updates available if there are sever problems.
For every choice you offer to the user a line of updates is supposed to
exist. So such choice is represented by a package name. So if you want
to give the user choices about different major or major+minor versions
each of those need an own name - generated by appending the part of the
version that is fix withing this line of updates to the name.
probably my largest use case will be the supplanting or replacement of
jar files in the jboss deployment directory.
example 1:
pwel-ejb-2.5.0.9.rpm is installed on the server.
pwel-ejb-2.5.0.9.rpm has as single jar file in it - PWEL-EJB.jar
this file would be deployed to:
$JBOSS_HOME/server/default/deploy/
and over write ANY other file with that SAME name.
well, this is not the way rpm works. RPM takes care of every file and
makes sure non of them get overwritten. The right way to replace one
file is to remove the package containing the previous version. This is
either done when updating a package or - if the file is owned by package
with a different name - by removing this package first by hand.
> If foo1 and foo2 contain the same files you should set a conflict
> between them.
ok - you lost me here.
To make it easier to the system that two packages contain files that
conflict (have same file name but different content) you should flag the
packages as conflicting by hand by adding "Conflicts: othername <=
version-release". (If you are sure about what you are doing you can
omit the version qualifier)
this is the way jboss works - you simply drop the new jar file in to
the /deploy directory and jboss does the rest.
this is a simple use case - but an important one for me.
example 2:
pwel-ejb-2.5.0.9.rpm is installed on the server.
pwel-ejb-2.5.0.9.rpm has:
1) a jar file ( PWEL-EJB.jar)
2) a mysql database script.
3) a shell (bash) script to run the database script
the jar file would be deployed to:
$JBOSS_HOME/server/default/deploy/
and over write ANY other file with that SAME name.
rpm would invoke the shell script which in turn would run the database
script.
does all of this make sense from an rpm perspective ?
Having two packages with the same name (and even version and release)
containing different contents is just asking for trouble. If there are
several uses for the jar file package it separate from the mysql stuff
or at least make the two packages with a different name.
If you package the jar separately you could make the package with the
mysql script Require: the package with the jar file to make sure
Florian
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
