Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Linux Software

FreeBSD Ports for GNU/Linux 294

proclus writes: "GNU-Darwin has provided a special FreeBSD ports tarball (20 Mb) for GNU/Linux users. We have modified the FreeBSD Ports System to bring thousands of free software offerings within the reach of every GNU/Linux user. The system is not fully automated yet, but you can untar it in your home directory and try it. Just follow these directions. This system provides full access to the FreeBSD ports, so that users can compile and install software in their home directories. Root access is not required."
This discussion has been archived. No new comments can be posted.

FreeBSD Ports for GNU/Linux

Comments Filter:
  • by FreeUser ( 11483 ) on Friday September 21, 2001 @02:49PM (#2331142)
    How is the ports system an improvement over Debian's apt-get system?

    First, I am a real fan of Debian, apt-get, and am running debian both at work and at home. .deb's and apt-get are IMHO as good as it gets when distributing, managing, and upgrading binary packages.

    What the FreeBSD ports system does which is so cool is get rid of the idea of distributing binaries at all. Instead, you go into the subdirectory corresponding to the program you want and type "make install." Based on the skeleton files present the program source(s) and any patches are downloaded, applied, the program is then compiled against whatever libraries you have on your system (no more "this binary requires glibc version Y but you only have X"), and installs the compiled binary. Furthermore, doing so is as easy as installing a .deb or .rpm, meaning relatively inexperienced users can do this. Dependencies are simpler (you only need what is required to compile the program, and such dependencies are also automatically downloaded and compiled at the same time. You do not need particular software versions based on what the binary was compiled against.)

    Basically, it combines "apt-get source --compile; dpkg -i [new-packages].deb" into "make install," and simplifies the package management/dependency management.

    BSD ports is IMHO the only software management system that in some ways exceeds even debian's approach, but keep in mind there are conceptual differences to the approach (all things source vs. precompiled binaries), so it isn't entirely an apples to apples comparison.
  • Re:GNU/Linux (Score:3, Insightful)

    by Reality Master 101 ( 179095 ) <<moc.liamg> <ta> <101retsaMytilaeR>> on Friday September 21, 2001 @02:50PM (#2331155) Homepage Journal

    I will never, ever call Linux by that name. If I ever meet RMS, I won't use the term, either. He can correct me over and over (as he is notorious for doing), and I will never, ever EVER EVER use that idiotic term.

    My goal is to not cave in to the "language police". The GNU component is only one component of a Linux distribution. The Kernel is called Linux. A distribution is typically called Linux. I am not confused by this. Most people are not confused by this.

    I wonder what the goal is of dening the Free Software Foundation credit for things such as the GPL and kicking off gcc, etc.?

    I wonder what RMS's goal is for denying other parties credit for things such as XFree86, Perl, etc. GNU's stuff is only piece. Certainly an important piece, but only one piece.

  • by sbeitzel ( 33479 ) on Friday September 21, 2001 @03:19PM (#2331296) Homepage Journal
    Well, actually, this won't provide you with any new programs. What this is really about is giving everybody FreeBSD's version of apt-get-source (from what I understand of Debian).

    My guess is that this tarball differs from the ports tree that's available via cvsup (cvsupXX.freebsd.org, where XX is some number on the interval [1,10]) in that the cvsupped ports contain patches that are FreeBSD specific, while this tarball will have settings more appropriate for Linux, such as /tmp rather than /var/tmp, /usr/bin instead of /usr/local/bin, /etc/rc.d instead of /usr/local/etc/rc.d, et cetera.
  • by Brian Feldman ( 350 ) <green@Fr e e B S D . o rg> on Friday September 21, 2001 @03:44PM (#2331478)
    Upgrade a system library in what way? If a library is upgraded to a newly-incompatible API/ABI, the version number will be bumped so everything which used to use it will remain doing so until it is recompiled (and possibly adapted if it used an API in a deprecated way). APIs don't usually get deprecated, but ABIs changing isn't unheard of.

If you have a procedure with 10 parameters, you probably missed some.

Working...