You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2008/04/03 03:50:37 UTC
[ApacheDS] Installer file naming convention
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)
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.
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?
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)
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
So that gives us some relative consistency. WDYT?
Thanks,
Alex
Re: [ApacheDS] Installer file naming convention
Posted by Alex Karasulu <ak...@apache.org>.
On Thu, Apr 3, 2008 at 3:44 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>
wrote:
> Hi Alex,
>
> On Thu, Apr 3, 2008 at 3:50 AM, Alex Karasulu <ak...@apache.org>
> 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
Re: [ApacheDS] Installer file naming convention
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Alex,
On Thu, Apr 3, 2008 at 3:50 AM, Alex Karasulu <ak...@apache.org> 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.
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.
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.
> 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.
> 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 ;) )
Pierre-Arnaud