Re: regular (aka bsd) compress distribution?
Marek Michalkiewicz says:
> Red Hat, Slackware, FreeBSD, ... all have compress as part of the
> standard distribution. I don't think they all would do something
> that is against the law. Maybe something is wrong with the Debian's
> interpretation of the patent?
Infomagic's December cut of Linux sites had to remove stuff from
Slackware. Just because it is in another distrib doesn't make it
so. The algorithm compress uses is copyrighted and including it
without permission would be IMHO playing with fire. Considering
gzip does such a good job, it hardly seems worth the risk to include
compress/uncompress. If we did, I think it'd have to go in non-free
and we would, as Marek suggests, have to ask Unisys.
> Too bad dpkg can't (yet) install RPMs. It would be nice to be able
> to buy a 5 CD set with both Debian and Red Hat, install Debian, then
> install the missing non-free-in-Debian-free-everywhere-else packages
> from the Red Hat CD. It shouldn't be impossible - most differences
> I've seen so far between these distributions are in startup scripts.
> And commercial software will ship as RPMs soon...
.deb and .rpm files are more than just fancy .tgz files. What you
suggest would require that .deb file dependencies be able to track
.rpm files and that dpkg know, perhaps via an index file, what .deb
files the .rpms depend on. Of course, the rpm-s would never be
maintained for us and their contents could change without warning.
In effect, the rpms would be worse than orphaned .deb packages. If
orphaned packages are only barely supported by Debian, rpm-s will likely
never be. It would be far less effort for us to just package those
items as .deb files (if we have a maintainer for it).
If you really want to install an rpm, get the Red Hat package
maintenance system. But be warned, you can damage your existing
system.
I wouldn't do it.
Oly
Reply to: