Dominique Dumont wrote:
> bob@proulx.com (Bob Proulx) writes:
> >> #rpm -ivh myproduct-xxx-xx.rpm
> >
> > As other people have written doing this is not a good thing. Put
> > yourself in the other position. I have a .deb file from Debian. I
> > want to install it on a RH system. Should I insist that you must use
> > dpkg to install it there? That would be just as silly as insisting
> > the reverse. A native packaging is always best.
>
> Sure. Be if one can easily install rpm packages on a Debian system,
> this would be a good message sent to the corporate world.
Ian Murdock <imurdock@progeny.com> wrote the following a while back.
I am very interested in how it turns out.
http://lists.progeny.com/archive/discover-workers/200310/msg00000.html
Summary snippet:
We are also working with various parties to add/merge RPM support
into the mainline APT, to allow Debian- and RPM-based
distributions to be managed using a single APT codebase, and
possibly even to allow Debian and RPM packages to coexist side by
side. This work also aims to merge our various APT extensions
(e.g., support for authenticated APT repos) into the mainline APT.
It is our hope that a distribution-independent Anaconda and
a distribution-independent APT (plus, eventually, a distribution-
independent configuration framework) will, along with a
stronger LSB, help unify further the various Linux distributions.
So there is hope for your goal. But it is not here yet. A problem to
be handled will be different distro policies. Look at the recent
issues just discussed about installing and maintaining KNOPPIX on a
hard drive. A fine system. Based on Debian. But still there are
issues about interoperating packages. If something that close can't
work transparently how well can packages crossing really different
distros operate? I am skeptical. But cautiously hopeful.
> Currently there is big chicken and egg problem with Debian in the
> corporate world. Corporate guys want to be able to install software
> from ISV (like Oracle).
I understand what you are saying. But they can install oracle and
others today. My comment is that they want a vendor supported
installation of the vendor application. Not an installation that a
Debian expert made happen.
> ISVs only provide their proprietary software as rpm because not many
> corporation ask for Debian. Corporation do not ask for Debian because
> most ISVs don't provide Debian packages.
We ask routinely. We get stone-walled routinely. But we do it
anyway. However we have a lot of in house Debian expertise at my
place of employment. Enough that vendor support was not the biggest
lever.
We do keep one RH machine (one vendor's supported platform, I am in
the USA) so that when we need to bring a vendor in on a problem we
recreate the problem there. Problems have always been identical in
behavior on Debian systems too. But the vendor won't acknowledge it
until we can get them a test case on their system. And by that I mean
a system on the vendor's developer's machine.
In the end I think we just need to wear down the folks supporting a
particular distro instead of supporting GNU/Linux in general. And I
am starting to see headway with our vendors. But it is slow going.
> IMHO, the only way to break this circle is to provide a way to install
> rpm that doesn't look like a hack.
I previously gave one example of the MTA differences between distros.
But let's take something simple which might seem reasonable to alien
install like ncurses4, /usr/lib/libncurses.so.4. A common
compatibility library needed for many RH programs to run on Debian.
Woody does not have this. I think potato did and it was dropped and
is now back in sarge.
If you alien the RH package and try to install it on Debian it will
install fine. Programs will work. But then eventually you will
install a Debian package which requires not ncurses4 but libncurses4.
The names won't match. If you try to install libncurses4 it will have
file conflicts with ncurses4. If you try to remove ncurses4 first you
will have dependencies problems. Anything built with ncurses4
installed won't know about libncurses4. Yes, this is all from
personal experience. I created my own problems by not following the
right policy.
How do you propose to handle this type of case? Note that I am not
disagreeing in principle to the fact that this would be beneficial. I
agree with that. I am just asking how would this actually be done. I
do not think it is possible. But I am very happy if I am proved wrong.
> So the questions are now:
>
> - does the Debian community want Debian to be used in corporate world
> to run *proprietary* softwares ?
Personally, yes. I think many people have that ideal. It is written
into the Social Contract. But the recent Debian Social Contract vote
casts that as a majority opinion into doubt. So now I don't know. A
contingent of vocal DDs would certainly say no.
> - Can tool like 'drpm' be reliable enough ?
Look to 'alien' for the best track record we have so far for this type
of tool. The answer is, "Not yet."
Bob
Attachment:
pgp2ISnHEXrxh.pgp
Description: PGP signature