Lennart Sorensen wrote:
> For the kind of cash the enterprise vendors tend to charge, yes actually
> now that you ask, I think I can expect them to figure out dependancies
> and making proper packages.

.... by making reasonable assumptions about what is on the system based
on a standard install of $version of $distribution.

Asking enterprise vendors to support your (customised, hacked-up,
non-standard) OS install is, um, unlikely. Unless you're paying them
enough for them to completely mirror your environment in the dev lab and
certify their product on *your* particular combination of software. (Of
course, most people running mixed-version Debian systems are unlikely to
be buying enterprise software like Oracle. )

(This is drifting off from my original question: what simple test(s)
for uniqueness can I use to determine which version of which
distribution I'm on? FWIW, it seems that for my purposes, the contents
of /etc/debian_version and the full version+release string from the
base-files package are sufficiently unique.)

-kgd


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 05-Jun-07, 08:37 (CDT), Kris Deugau wrote:
> Lennart Sorensen wrote:
> > For the kind of cash the enterprise vendors tend to charge, yes actually
> > now that you ask, I think I can expect them to figure out dependancies
> > and making proper packages.
>
> ... by making reasonable assumptions about what is on the system based
> on a standard install of $version of $distribution.
>
> Asking enterprise vendors to support your (customised, hacked-up,
> non-standard) OS install is, um, unlikely.

No, I'd ask them to build correct packages for the current stable
version, e.g. etch. If they've got their dependencies correct, I should
be able to install packages from other releases without too much
anguish.

Of course, if I have problem, I shouldn't be surprised to hear "we can't
duplicate it on our pure etch system..."

Steve

--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue, Jun 05, 2007 at 09:37:58AM -0400, Kris Deugau wrote:
> ... by making reasonable assumptions about what is on the system based
> on a standard install of $version of $distribution.

Well too many seem to assume that you are running some version of
redhat, and that redhat equals linux and there are no reasons to
consider anything else.

> Asking enterprise vendors to support your (customised, hacked-up,
> non-standard) OS install is, um, unlikely. Unless you're paying them
> enough for them to completely mirror your environment in the dev lab and
> certify their product on *your* particular combination of software. (Of
> course, most people running mixed-version Debian systems are unlikely to
> be buying enterprise software like Oracle. )

Sure. If I say I run debian sarge, and I install the .deb for debian
sarge, it should work, unless I have mixed in stuff that isn't part of
sarge, in which case that would be my problem. So yes as long as they
provide a proper .deb targeted at sarge, that would be fine. Of course
Etch would be more interesting than Sarge by now.

> (This is drifting off from my original question: what simple test(s)
> for uniqueness can I use to determine which version of which
> distribution I'm on? FWIW, it seems that for my purposes, the contents
> of /etc/debian_version and the full version+release string from the
> base-files package are sufficiently unique.)

Certainly the /etc/debian_version is what I would rely on.

--
Len Sorensen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Jun 04, 2007 at 04:16:29PM -0400, Lennart Sorensen wrote:
> On Sun, Jun 03, 2007 at 11:16:08PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
> > Think about Enterprise (non-free) software like Oracle, HP Openview, Tivoli,
> > Remedy... Do you expect vendors of this software to understand^Wimplement
> > package management based dependencies for *all* Linux distributions?
> > LSB tries to simplify the Linux environment for such software. Lsb_release
> > is defined as the an answer to the question "which distribution am I running
> > in and which release is it?"
>
> For the kind of cash the enterprise vendors tend to charge, yes actually
> now that you ask, I think I can expect them to figure out dependancies
> and making proper packages. Opera seems to manage, and they are giving
> away their non-free software for free. Managing to package and test
> your code on most major distributions is actually a good way to ensure
> the programmers didn't go do something stupid that is going to cause
> problems later.

I'm afraid you're comparing apples and oranges here.

Opera is a rather small product and codebase when compared to the products of
any of the Enterprise software players I placed above. In some of the
examples I placed above a software release of a given version of their
product is made up of 4-5 CDs of binary software. Opera is, what, a 4-7 MB
download?

Believe me, people running Linux and using this kind of software will, in
most cases, not get a package integrated into their $distribution package's
management system but an installation program from the vendor that works by
its own rules.

The funny thing is, some of these installation systems actually installs a
package management system of itself which is completely unrelated to the
system's. That's the case of HP's depots, the package management system for
HP-UX, which is also used in software like HP Openview when installed in
other operating systems too (at least I know of Sun's Solaris and IBM's AIX)

And, even funnier, those that *do* provide packages (RPM packages in all the
cases I've stumbled upon) don't setup proper dependencies so even if they
install fine on a system they were not prepared for (think SuSE vs. RedHat)
they just don't run. Vendors just use the package management system as an
archiver (a 'bigger' tar.gz or zip file if you will).

Many organisations I've worked with in Spain (including Telcos and Banks) pay
large amounts of cash in licenses to these (overseas) software vendors and
no, they are not pushing them to get packages for their favorite
distribution. They just push them to make it *works* (i.e. run and be
supported) in $distribution and are not always succesful (which means they
have to install the vendor software in the official/supported/approved
platforms the vendor has decided upon).

Long-term, the fact that the software was installed using a .deb, .rpm, an
installation script or a tar.gz is not important at all. Having the vendor
support your environment is.

Regards

Javier

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGZeXEsandgtyBSwkRAghfAJ9JRhEPqPff4f5k70MKuA ES32TIFgCdEona
0jauRU6IXOkb+Z6Vxchujjg=
=ebhp
-----END PGP SIGNATURE-----