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
