2:43 p.m.
>>>> "kazz" == Kazuyuki IENAGA
<ienaga(a)jsys.co.jp> writes:
kazz> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
kazz> Could the binary kit for each OSen use each package style rather than
kazz> _normal_ *.tar.gz as some binary kit had been made as RPM for Linux
kazz> distributions in previous release?
>
> Why?
kazz> I thought:
kazz> - Can't it reduce the cost for installation for system admin?
kazz> - Can't it reduce the cost for building binary kits because major
kazz> operating systems often provides XEmacs in their
kazz> distributions. For me, I made FreeBSD version of binary kit in
kazz> previous two releases. But I think most of FreeBSD users
kazz> installed XEmacs from its package distributed, not binary kit.
Not me.
The problem is that all packaging systems I've seen (FreeBSD, AIX,
Solaris, RPM) are quite inflexible, especially in environments with
distributed multi-architecture multi-version shared software
installations where they are completely unuseable. Software which
only exists in a native-packaged format therefore greatly *increases*
the sysadmin cost out here.
We've gone to great pains to make XEmacs binaries rather independent
of the layout into which it is installed. Our tarball layout allows
people to put the stuff pretty much wherever they want. It allows the
same install documentation to be shared among architectures.
Therefore, it is desirable to have all binary kits in the same general
format. Having native packages as an add-on is certainly a good
thing, but not in the absence of a regular binary kit.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
3:32 p.m.
New subject: binary kit and packaging
Michael Sperber [Mr. Preprocessor] writes:
| We've gone to great pains to make XEmacs binaries rather independent
| of the layout into which it is installed. Our tarball layout allows
| people to put the stuff pretty much wherever they want. It allows the
| same install documentation to be shared among architectures.
| Therefore, it is desirable to have all binary kits in the same general
| format. Having native packages as an add-on is certainly a good
| thing, but not in the absence of a regular binary kit.
Well, as I said the most benefit I see in being able to remove the
files I installed once. (BTW, I think the perception of having XEmacs
in the platform specific package format is definitely higher.) So at
least we could start to think about an uninstall script to include
into the distribution.
BTW, why do we do a binary kits for Win9x/NT using InstallShield then?
I guess because of perception!
6:25 p.m.
New subject: binary kit and packaging
Charles G Waldman writes:
| Marcus Thiessel writes:
|
| > BTW, why do we do a binary kits for Win9x/NT using InstallShield then?
| > I guess because of perception!
|
| Who did a binary kit with InstallShield?
As I remember correctly there was (and maybe is) somebody to
experiment with InstallShield? Was it Darryl Okahata?
Anyway, the Win9x/NT folks I guess will love to see such
installer/de-installer bundle, right!?
7:49 p.m.
New subject: binary kit and packaging
Marcus Thiessel <marcus(a)xemacs.org> wrote:
Charles G Waldman writes:
| Who did a binary kit with InstallShield?
As I remember correctly there was (and maybe is) somebody to
experiment with InstallShield? Was it Darryl Okahata?
No! ;-)
I've appended a copy of the original annoucement.
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
===============================================================================
Date: Sun, 25 Apr 1999 19:39:37 -0400
From: E Kovarski <edwardk(a)digitalized.com>
To: xemacs-nt(a)xemacs.org
Subject: Binary Kit Available; 21.0.67 (MSVC++ Compile)
An experimental installer for XEmacs 21.0.b67 is presently available from
http://www.attcanada.net/~markk/xemacs/
The installer is quite large, ~30mb, as it includes /all/ packages and
support files. The original plan was to make an InstallFromTheWeb
installation available but unfortunately I have run into a bug with the
software. InstallShield Pro v5.53 is unable to build the media in more
sensible chunks, such as 256kb, for the InstallFromTheWeb client.
Once the bug has been squashed by InstallShield Corp, users will be able to
select which components to download and install, without any padded
overhead.
I would appreciate any feedback on the installer and suggestions,
especially since it now attempts to mirror the directory structure used by
the unices. This allows it to run without having to modify the registry.
The three installation modes presented during setup are Typical, Compact
and Custom.
Typical will install the binaries (including auxiliary files, such as GNU
Diff), support files and the recommended packages, e.g. text-modes, efs,
prog-modes, etc.
Compact is essentially a Typical install minus the packages.
Custom is self describing. Do keep in mind that the installer does
dependency checks and automatically selects packages required by other ones.
After the install has finished, you can optionally register xemacs.exe and
runemacs.exe in the registry under the AppPaths tree to be able to start it
from Start | Run.
-Edward
6:14 a.m.
New subject: binary kit and packaging
Darryl Okahata writes:
| Marcus Thiessel <marcus(a)xemacs.org> wrote:
|
| > Charles G Waldman writes:
| >
| > | Who did a binary kit with InstallShield?
| >
| > As I remember correctly there was (and maybe is) somebody to
| > experiment with InstallShield? Was it Darryl Okahata?
|
| No! ;-)
Sorry! Forgive me! Sometimes I have a memory leak. :-( Anyway, I
didn't want to blame anybody. I just wanted to point out that we are
already using some of the specific software management systems.
9391
days inactive
9391
days old
5 comments
4 participants
participants (4)
-
Charles G Waldman -
Darryl Okahata -
Marcus Thiessel -
Michael Sperber