On Thu, Apr 3, 2008 at 3:44 AM, Pierre-Arnaud Marcelot <[EMAIL PROTECTED]> wrote:
> Hi Alex, > > On Thu, Apr 3, 2008 at 3:50 AM, Alex Karasulu <[EMAIL PROTECTED]> > wrote: > > > It would be nice if we used a convention for the names of the generated > > installers. Here's what we have right now from what I can build on this > > machine: > > > > apacheds-debian-<arch>-<version>.deb > > apacheds-server-<version>-<arch>.rpm > > apacheds-linux-<version>.bin > > > > First I know this apacheds-server base name in the RPM is from the old > > installer days. It's a bit redundant, so why don't we just use 'apacheds' > > as the package name base for everything. No need to use apacheds-server. > > > > Same thing for apacheds-debian. I think it's pretty clear this is for > > debian because of the file extension. I don't think we need to add debian. > > > > Also we should probably have the architecture after the version. So we > > would have something like this: > > > > apacheds-1.5.2-ppc.rpm > > apacheds-1.5.2-x86_64.rpm > > apacheds-1.5.2-sparc.rpm > > apacheds-1.5.2-x86_64.rpm > > > > apacheds-1.5.2-ppc.deb > > apacheds-1.5.2-i386.deb > > apacheds-1.5.2-sparc.deb > > apacheds-1.5.2-x86_64.deb > > > > I don't know the names of the installers generated for Windows and Mac, > > but if we follow the same convention: > > > > apacheds-1.5.2.dmg (arch not needed as you said) > > apacheds-1.5.2.exe (arch not needed again) > > > +1 for this naming scheme. > I can change it in the installers pom.xml if you like. > Cool if that's not a hassle. I can do it as well, although I'm just about to crash. > > Again from my understanding the executables for Mac and W$ will run on any > > architecture for those operating systems. I want to test this to make sure > > though if you have not already done that, let me know. > > > I'm sure for the mac version as we're using the universal binary of the > wrapper. > I don't know for Windows, I don't have a 64 bit Windows to test it on. > If the Windows version is i386 it should run on both. I just have to test it. > > Now the bin installer is the odd ball. > > > > (1) Will this run on all architectures as well? > > (2) Will it produce an installation layout that can be used on multiple > > *NIX operating systems? > > > (1) I think I had set this up with a x86 version of the wrapper for the > most commonly used system. > We can add another binary installer for a 64 bit too if you like. > No problem this is fine. Perhaps in the future we can modify the init script and include all the wrapper executables for *NIX in one generic installer. That way based on the $OS it can use the right wrapper. We could even use the *.bin on Mac. Even Windows if cygwin or some other shell is installed. Just an idea tho. > > > > > If so then I guess we can just use the same scheme as we do for the Mac > > and W$ installers but instead of using the *.bin extension maybe we can use > > the *.sh . This gives a clear cue to the user that it's a shell script > > installer here's what that would look like: > > > > apacheds-1.5.2.sh > > > > (presuming arch/os not needed if init script uses different bundled > > wrapper executable) > > > Well, to me it more a small shell script in a large binary file than a > large shell script including a small binary part, but as you like. > It like the binary installer for the JVM which you can download from Sun. > But if you want to switch the extension to sh, it ok. > No problem you make a good point. Either way I'm happy. > > > > > I guess eventually we'll also have Solaris packages and that presents > > the whole sparc verses intel architecture classification. But this scheme > > will support that: > > > > apacheds-1.5.2-sparc.pkg > > apacheds-1.5.2-i386.pkg > > apacheds-1.5.2-x86_64.pkg > > > +1 for this too, as soon as we have this installers. (Soon ;) ) > I included these here to make this email complete with all the possibilities. Thanks, Alex
