Re: Debian, rpm and corporate world
bob@proulx.com (Bob Proulx) writes:
>> 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.
Exactly.
> 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.
IMHO, packages names and packages versions are only some kind of
shrink-wrap for the distributed files. Dependency problems boil down to
the fact that a file version x depends on a set of files of version
x,y,z.
So, the only common ground between distro are the files names and
location and upstream version. So we must work on that.
One way to solve the problem you mention is to fall back on checking
the dependencies wrt the content of the packages (i.e the files).
E.g:
- foo.rpm requires libncurses4.rpm.
- no libncurses4.deb is found
- some rpm database (on disk or on-line ?) is queried for the content
of libncurses4.rpm
- some rules (to be defined ...) are applied to avoid requiring
unnecessary files (like package doc ?)
- Debian database is queried for missing files, ncurses4.deb and
bar.deb (for the same of the example) contain these files
- install ncurses4.deb and bar.deb
- install foo.rpm
The file dependency checking must be completely done by the tool. We
can't ask people to interfere in this area, this is too complex.
This approach raises some non-obvious problems:
- the rpm database must refer to a well-known and maintained rpm
repository with some consistent naming policy (Suse ?)
- the files are installed in standard location independent of the
distro (LSB compliance ?)
- there must be a consistent way to identify the upstream version of
each package (rpm or deb), lest version dependencies will not be
satisfied
[ I not sure that I have proved you wrong yet ... ;-) ]
>> - 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."
Alien does a decent conversion job. Except for the dependency part.
Cheers
--
dominique.dumont@hp.com
Reply to: