Creating a massive RPM is one way to go.

The one I'm creating
creates a minimal RPM that excludes
all dependencies.

The RPM Factory will package all the dependencies.

It can do this right now, but I took a break from
it to work on the DAS stuff, so I still need to "Prove It" :-)

Now I'm taking a break from the DAS to setup the test
environment for this.

yum will pull the minimal RPM and it in turn will
pull all the dependencies (Other RPM Packages).

I'll try to put the reworked shell script (Which
includes all the FHS thinking out this week)
so that others interested can have a look.

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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:ole.ersoy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> 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/brow...action_12494305
>     <https://issues.apache.org/jira/brow...action_12494305>
>     ] 
>     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. 
>     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. 
>     https://issues.apache.org/jira/browse/DIRSERVER-749 
>     apacheds-branch-1.0-server-installers-rpmfix.patch,
>     apacheds-daemon-trunk-rpmfix.patch 
>     out of the box: 
>     $USER, which is not defined at boot time 
>     with chkconfig or similar 
>     silently overwritten when one upgrades the RPM 
>     ${name}-${version}-${release}.${arch}.rpm 
>     version dependent, making upgrades cumbsome. The admin has to
>     relocate the partitions and config files on every updgrade. 
>     are not necessary for operation. 
>     security and safety reasons. 
>     a 'rpmbuild --rebuild' with it. 
>
>

[ Post a follow-up to this message ]