Oh - Forgot to mention - The RPM Factory
includes the version number in the RPM package,
so all versions of a Maven artifact can exist side by side
as RPMs.
So if Tomcat depends on commons-logging 1.5.2
and ADS depends on 1.3.2, yum would pull each
of these and install the jar artifact in
/src/lib/java
...I think that's the FHS directory...
Gotta refresh myself :-)
Cheers,
- Ole
Alex Karasulu wrote:
Yeah this is bad. I figured this would be the case tho since you cannot
install more than one version of a package and dependencies will cause
some collisions. I don't think we can depend on this and need to
package our dependencies into a single RPM.
Alex
On 5/8/07, *Ole Ersoy* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I was really excited about JPackage until I found out that they have
1 version of each "Package" that they support per release.
Meaning they have JPackage 1.5, 1.6, 1.7...that are "releases"
of their packages. Each release should support 1 version of
1 package.
Each such release has to have one supported version of a package.
So suppose Tomcat and ApacheDS share a dependency.
ApacheDS uses version 1.3 of this dependency in the current
build.
Tomcat uses 1.5.
So what happens?
Suppose someone at JPackage already built
version 1.4, and they tried it with both Tomcat and ADS,
and it looks like it works.
Well, if that's the supported version in release
1.x of JPackage, then this dependency could end up getting shoehorned
into a ADS install that JPackage supports.
Personally I think that's really scary.
Originally I was writing a Maven plugin for them to automate
their work, but decided to go in another direction when
I found out about this policy.
Cheers,
- Ole
Alex Karasulu (JIRA) wrote:
> [
https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305
<https://issues.apache.org/jira/browse/DIRSERVER-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494305>
]
>
> Alex Karasulu commented on DIRSERVER-749:
> -----------------------------------------
>
> NP Bastiaan, it's hard to align at times. Oh I did not know
about the JPackage rpm. Perhaps we need to look at that. None of
us besides Ole have been in contact with the JPackage
folks. Perhaps you can point us in the right direction so we can
see and discuss what they have done.
>
> BTW Chris Custine is now looking at rewriting some of the code in
the daemon and installer modules to properly generate an RPM with
scripts that actually work out of the box. He's primarily focused
on the 1.5 branch and will be switching us over to use the Tanuki
wrapper instead of jsvc and procrun. As for 1.0 I don't think it's
worth mucking with.
>
>> fix issues with apacheds RPM to get it working out of the box
>> -------------------------------------------------------------
>>
>> Key: DIRSERVER-749
>> URL:
https://issues.apache.org/jira/browse/DIRSERVER-749
>> Project: Directory ApacheDS
>> Issue Type: Improvement
>> Components: installer-plugin
>> Affects Versions: 1.0.1, 1.0
>> Environment: linux
>> Reporter: Bastiaan Bakker
>> Assigned To: Alex Karasulu
>> Priority: Minor
>> Fix For: 1.5.1 , 1.0.3
>>
>> Attachments:
apacheds-branch-1.0-server-installers-rpmfix.patch,
apacheds-daemon-trunk-rpmfix.patch
>>
>>
>> The apacheds RPM has several issues that prevent it from running
out of the box:
>> * the init script fails to run because APACHEDS_USER is set to
$USER, which is not defined at boot time
>> * the init script fails to run bevause JAVA_HOME is not defined
>> * the init script it is not registered to the init subsystem
with chkconfig or similar
>> * the config files are not marked as such, causing them to be
silently overwritten when one upgrades the RPM
>> * the RPM filename is not conform conventions:
${name}-${version}-${release}.${arch}.rpm
>> * the location of the files (/usr/local/apacheds-1.0_RC4) is
version dependent, making upgrades cumbsome. The admin has to
relocate the partitions and config files on every updgrade.
>> * the sources and docs are included in the rpm, even though they
are not necessary for operation.
>> The RPM build mechanism for apacheds also has some issues:
>> * runs rpmbuild as root, which is frowned upon by RPM gurus for
security and safety reasons.
>> * the generated src.rpm is not self contained, ie. one cannot do
a 'rpmbuild --rebuild' with it.
>> * the sudo mechanism is totally unnecessary
>>
>
