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 Wed, 09 May 2007 14:21:55 GMT


Alex Karasulu wrote:
> I'm of the mindset to use the FHS layout as much as possible while still 
> adding all the
> dependencies with an uber RPM.  The other way around might be attempted 
> later since
> it's more complex and probably will lead to some breakage.
> 
> So let's just go with the uber RPM now using the right layout especially 
> the one that
> Chris recommends for being able to have multiple instances using the 
> same software
> installation.  

The way I'm doing it will also allow for
multiple instances.

This will be huge and more than enough for me.
> 
> If Ole you have time to research the alternative approaches we can look 
> into them but
> really it's not that critical.  

I wish I had time to work on both approaches.

I invested well over 3 months solid looking into
an learning the intricacies of JPackage while
trying to create a maven plugin that automates all their work
for them.

I personally need the RPM installer I'm designing, thus
I'm proceeding full steam with it, but I'll be glad to help
transfer knowledge from this process if Chris wants to work
on the UBER RPM.

We have some major priorities that far
> supercede following
> the JPackage approach.  Let's keep it simple for now.

Sure.  What I will do is just check it into my sandbox
along with a Eclipse Plugin User Manual and anyone who
wants to can have a look at it.

> 
> Alex

Cheers,
- Ole


> 
> On 5/9/07, *Ole Ersoy* <ole.ersoy@gmail.com 
> <mailto:ole.ersoy@gmail.com>> wrote:
> 
>     The reason I'm putting all dependencies in
>     /src/lib/java (FHS Location)
> 
>     is that now becomes the central location for all java libraries
>     / jar artifacts.
> 
>     Right now if both Tomcat and ADS are running on the same machine,
>     they duplicate a lot of the dependencies.
> 
>     With this there is no duplication.
> 
>     When OSGi gets going, it also makes
>     /src/lib/java a "OSGi" service bundle repository,
>     from which the OSGi container can load all services.
> 
>     The RPM Factory can insert OSGi manifests.
> 
>     So if it's hooked up to something like archiva it
>     can convert an entire repository.  Does depend
>     on "Clean" pom files though.
> 
>     The approach also makes download more efficient since
>     the ADS RPM is minimized.
> 
>     I think most administrators would prefer the FHS compliant approach.
> 
>     Anyways - I'm sure others might like the "Uber" RPM as well,
>     so we could always do both.
> 
>     Cheers,
>     - Ole
> 
> 
> 
> 
> 
> 
> 
> 
> 
>     Chris Custine wrote:
>      > 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
>     <mailto:akarasulu@apache.org>
>      > <mailto: akarasulu@apache.org <mailto: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
>     <mailto:ole.ersoy@gmail.com>
>      >     <mailto: 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
>     <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