> Oops. Next time, you might want to stage the upgrade, test your
> packages still build and then do it on the live system.
So you have to have two boxes every time you upgrade? This is a
"good thing" (TM)?
> Do you have some error messages though? It might just be trivial.
The BUILDROOT macro expands to a repeat of my home folder plus
an offset.
> Is your software proprietary? Is it niche?
Yes to both. That's why we're prepared to pay for service.
> All updates should be tested before deploying AND have backups available
> to restore the original OS/config. This is standard sys admin practice.
> You can't blame Linux for problems with your own scripts! If you had
> done this you could have just dropped back to 9.04, then investigated
> the problem on a clone/test box.
I'm not a sysadmin and don't want to be. Our job is to write
compilers and applications, mostly for embedded systems.
> You are probably approaching this problem from the wrong end.
> Think more about how a Linux user would like to install your software,
> and then fit in with that.
> An ubuntu user will just want to go to the "Software install" tool,
> click on the software name, and having it automatically install.
> At the command line, this is aptitude.
> They just want to do
> aptitude install mpeforth
Our users don't want to have to edit repository lists. They want
download, install, run. We try to provide what real users want.
Sysadmins are not "real" users.
> To package up the mpeforth for ubuntu probably requires one to have
> compiled it on the correct version of ubuntu due to different versions
> of libs existing on different versions of distribution. So, I suspect
> you will have to have one .deb for ubuntu 9.04, and a different one
> for ubuntu 9.10.
We ship compilers for six or more CPUs. Each compiler has four
editions (evaluation, lite, standard, developer). I already need
five packages (rpm32, rpm64, deb32, deb64, tarball) per edition.
That's 20 packages per compiler, and is already way too much.
On Windows we need four packages per compiler, and it works on
everything from Win98 onwards all the way to Windows7. Many of
our clients are only now saying to their clients that the base
system requirement is Windows XP. From XP onwards, we've had
only one change to make because of Windows API changes, and that
was really obscure (backspace handling to a RichEdit control
from a pipe).
Under Linux, we only rely on libc.so.6 and have not yet seen
problems - once the code is on the box and in the right place,
it just works. The problem is in getting it there.
> > 2010/1/14 Stephen Pelc <stephen@???>:
> > It is much the same with windows. Creating a package for windows 95,
> > or Windows 7 is likely to be different.
>
> I'm sorry to say that it's not :)
> There are a few differences in distributable files between versions, but
> nothing to warrant separate installers.
> (Of course, some people still insist on doing it...)
And the installers themselves work and are documented.
You can only improve something by acknowledging what's wrong
with it. There are things wrong with every version of every
operating system. Every time I get involved in one of these
discussions, I end up thinking that the way forward is Apple and
OSX. Ho, hum.
Stephen
--
Stephen Pelc, stephen@???
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web:
http://www.mpeforth.com - free VFX Forth downloads
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
