directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to get it working out of the box
Date Tue, 08 May 2007 23:18:55 GMT
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* <ole.ersoy@gmail.com 
> <mailto:ole.ersoy@gmail.com>> 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
>      >>
>      >
> 
> 

Mime
View raw message