llot...@web.de (Lothar Scholz) writes:
> Roger Leigh <${rog...@invalid.whinlatter.uklinux.net.invalid> wrote in message <news:87elav90qq.fsf@whinlatter.uklinux.net>...
> > llot...@web.de (Lothar Scholz) writes:
> > > > You should create a DEB or RPM package, and do the job properly.
> > > But i can't afford the time and money to test this on all
> > > distributions.
> > http://www.easysw.com/epm/
> > It's used by Easy Software Products (of CUPS fame) for their
> > commercial products (and it's GPL, too).
> > As for testing, your own home-grown installer will be *much* more
> > unreliable on all the different distributions. You can't expect to
> > get away without testing, whatever choice you make...
> Yes but i don't need X different distributions.
No, but with a simple $package.list file in the top level of your
source tree, you can build RPMs and DEBs with ease. if you ever need
to target a different operating system, the tool will let you do just
that.
> Quick typing error i mean:
> Most people don't have a root account, they can't store anything
> outside /temp and /home/myname. So they will never be able to
> install the program in /usr/local/bin, /opt etc.
Then, in addition to a binary package, ship a tarball which contains
bin, lib, etc, share directories etc which can be unpacked in any
directory: $HOME, /usr/local/pkg, /usr/local etc. and still work. A
lot of software is packaged like this.
> > It's an invasion of the user's privacy to alter *their* files. The
> I don't alter there files. If you see the home directory as a file
> then every program that stores data in
> "$HOME/.my-program-configuration" is unpolite.
No, they are created at runtime as part of the program's normal
operation. I have no problem with a program updating conffiles, or a
tool to perform the upgrade between two version, but the installer
shouldn't do this--require the user to run them explicitly.
> > > > Distributions like Debian and RedHat have a defined way of adding
> > > > programs to the menus of desktop environments and window managers
> > > > (update-menus). Why not do it the proper way?
> > > Same as GNOME and KDE. Why should i not use the Desktop ways.
> > You do not alter the *user's* files. You put the entries into the
> > *system's* menus.
> Again you are wrong, what file do i change ?
If you are running Debian, you create a file like this:
----------
?package(gnumeric):needs=X11 section=Apps/Math hints="Gnome,Spreadsheets" \
title="gnumeric" command="/usr/bin/gnumeric" \
icon="/usr/share/pixmaps/gnome-gnumeric.xpm"
----------
this is installed as /usr/lib/menu/$package and then the package
postinst script calls "update-menus" to have the program added to the
desktop menu. When the package is removed, update-menus is called
again (by postrm) and the entry is removed.
> If they don't want anything like this check don't need to mark the
> checkboxes of the installer program. But most normal persons like it
> to get an icon on the desktop which they can move around (to the
> taskbar or to the trash bin).
On Windows, maybe. I would suggest just adding it to the menus, like
above.
> > It works. That does not imply perfection.
> The current way is much more imperfect. You seem to be the typical
> geek using Linux as a server machine.
I'm running the Gnome desktop right now. Linux is not perfect by any
means, but the currently used package management systems are very
good. For the inexperienced user, there exist graphical front-ends to
ease their use.
> I i don't want to spend hours to find out how i must configure my
> desktop. Thats why linux is still not considered a good desktop os.
Configuring the desktop is documented in the User Guides for Gnome and
KDE. Individual programs have no right to be messing with an
individual user's settings though.
A "desktop" operating system can still be a "server" operating system
(whatever they are). Some people consider GNU/Linux to be a bad
desktop OS due to a lack of applications, but it's shortcomings are
not due to installers not being able to add an icon to a user's
desktop.
> > $ ldd `which gtk-demo`
> > libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x40023000)
> > libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x40035000)
> > libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x4008d000)
[snip]
> > libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x404a7000)
> > libm.so.6 => /lib/libm.so.6 (0x4050b000)
> > libc.so.6 => /lib/libc.so.6 (0x4052c000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> Someone developing an commercial application like this must be
> stuid:
Using libraries is stupid? This particular program targets a
particular "platform", in this case GTK+-2.0. It will run on any
system with the GTK+-2.0 libraries (most of this list is depended on
indirectly i.e. NEEDED by libgtk).
> I use:
> libX11, libXext, libm, libc, libdl, libgcc_s and /lib/ld-linux.so
That's fairly minimal, so there should be few problems.
> everything else is provided with the program and event this
> libraries are just 3,2 MB more to download from our website but all
> of these are in the linux standard specifications so there is no
> problem (i'm not 100% sure about libgcc_s)
libgcc_s is the gcc support library. It's needed, amongst other
things, for C++ exception handling IIRC. You can rely on it being
installed. If you write plain C, you probably use a static version.
> If you remove them it's your fault but we still cover this in our
> installation manual and FAQ.
That's fair enough.
> > In addition, consider the benefits of shared libraries. If just one
> > of the above libs had a security flaw or bug found, if would be *your*
> > responsibility to rebuild your program against the new libs and ship a
> > new version. With shared libraries, it's fixed by the distribution
> > vendor's security/bugfix updates.
> Yes but i have seen to many problems with persons changing some shared
> libraries and then nothing else worked. Unless you provide paid
> support i don't see this economically reasonable.
You can't prevent a user from messing their system up. If they do
that, it's their responsibility. If you used a binary package, the
package dependencies will prevent the program from becoming unusable
(unless they deliberately force the dependencies, which again will be
their responsibility).
With proper library versioning, there is little to worry about if the
user upgrades them (since the soname will remain constant as long as
the ABI is backward compatible). In practice, the incompatible
library package naming schemes that the RPM-based distribution vendors
use causes many more problems. Hopefully they will start to use a
common scheme in the future. This is probably the biggest problem
with RPM package building, but I admit I haven't used RPM packages for
a number of years.
> > > I think what you are missing by the most programs is a good
> > > installation manual that exactly tells you what is installed in what
> > > places, which files must be executable, which can be moved etc.
> > Do you mean the FHS? http://www.pathname.com/fhs/
> > or the LSB? http://www.linuxbase.org/
> No i mean what are the file that this program installed. I had to
> adminstrate the JRUN application server some time ago and it was
> terrible. No idea what the files where used to.
> > An installation manual is not something individual programs need worry
> > about, the specs are out there, so use them. If you use a binary
> > package, the user need only learn how to use that to install all
> > programs.
> But you still have to know much more as when you are using normal
> windows installer.
dpkg -i mypackage.deb
(install)
dpkg -r mypackage.deb
(remove)
dpkg -L mypackage
(list all files in installed package)
It's not that difficult, just a matter of reading the manual. Once
you know how to use it, you can use it to install everything, rather
than negotiating a different installer for every single piece of
software. The installation can be interactive too, asking the user
questions and giving feedback (have a look at debconf).
Or, apt-get install mypackage (and all the dependencies are resolved,
too). If you provided DEBs on your CD, you could just get the user to
# apt-cdrom add (add the CD to apt sources)
# apt-get install mypackage (do the install)
> > Find a better way to check licensing. For example, a *configuration
> > file* in the user's home directory. Patching binaries is so MS-DOS
> > (and ugly)!
> But an effective way to reduce piracy. If you ever have to work on
> your own selling software you would agree to my point of view.
No, it's doing it wrong. My point has nothing to do with not agreeing
with your goal, but rather with your way of doing it. Note that
piracy (unauthorised copying) and licensing (unauthorised use) are
generally two separate issues. Here, we are dealing with licensing.
If you have the program installed in a standard location
e.g. /usr/local/bin/myprog, every user can run it. However, if you
require a valid licence for each user, require them to have a valid
"key", stored as a dotfile in their $HOME. This could be readable
only by them, and so other users (without keys) can't run it. You
supply the key with each licence. This was (last time I tried it) the
approach taken by vmware, and kylix where you were emailed a key which
you just pasted into a named dotfile.
If you have a program the user runs to enter the licence key, the
program can then generate a new key from that, and do whatever magic
to make it unique that it likes e.g. tie it with the MAC address and
UID.
> > Software should work equally well when installed in /usr, /usr/local
> > or a user's home directory. Pre-compiled software should install into
> > a "system" location. I would suggest /opt for proprietary
...
read more »
by