directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <chris.cust...@gmail.com>
Subject Re: [jira] Commented: (DIRSERVER-749) fix issues with apacheds RPM to get it working out of the box
Date Wed, 09 May 2007 04:06:34 GMT
Personally, I favor the self contained, all in one RPM for distribution
where we can have better control over dependencies.  I wonder if there are
any good reasons to do anything else...

Chris

On 5/8/07, Alex Karasulu <akarasulu@apache.org > 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> 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
> > ]
> > >
> > > 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