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 <[EMAIL PROTECTED] > 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]> 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 > >> > > >
