Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Links Operating Systems BSD

Unified BSD packaging system? 108

Posted by Nik from the Must-get-around-to-playing-with-apt-get dept.
Chris Coleman is putting his money where his mouth is, after his recent suggestion that the BSDs need a unified package collection. The creation of www.openpackages.org was the next logical step, and Chris discusses this in his latest Daemon News editorial. With representatives from the three free BSD projects, as well as Apple (MacOS X) on board, this certainly has the potential to bring about closer ties between the BSD distributions at a level that will affect a lot of users.
This discussion has been archived. No new comments can be posted.

Unified BSD packaging system? More

Unified BSD packaging system?

Comments Filter:
  • The question is is the standard so good that Linux distro's will adopt it as well?

  • Whoo-Hoo! (Score:1)

    by Anonymous Coward
    Maybe now McKusick's characterizations of *BSD and Linux will finally be true (he describes *BSD as three kernels with one userland, and Linux as one kernel with lots of userlands).

    If I might suggest it, take a look at the Debian system for the Right Way to do packaging. It handles upgrades, it resumes downloads midpackage, and similar other features that all the *BSD packaging systems lack....
  • Slashdot posters need to check their links. The working link is here

    Disregard the above. It's a troll.
  • That is how the BSD's distribute files (source is the preferred). This is more concerning the package management.

  • Licensing (Score:4)

    by patreides ( 210724 ) on Sunday September 03, 2000 @07:38AM (#807680)
    How will all the BSDs choose an appropriate lisence for the packaging programs though? Seems like since each BSD has a different license they will all want the package system to be in their own native license, or have I been using Debian too long?

    Still this is an interesting concept, especially since not everyone can write portable code, and porting can then be done by one person and distributed as packages (I ran into this problem trying to get Mozilla to run on Irix, just reading the process turned me off)

    I also wonder what packaging systems it wil be based off of; will it be like RPM with lots of functionality but confusing or absent categorization (my RPM databases always turned into one package per category because I'd install mandrake or SuSE packages on top of RedHat), or will it be like .deb with a simpler style?
  • With FreeBSD I never ever have problems when dealing with rpms and failed dependencies or version xxxx of qt or gtk. Redhat was just a pain in my ass when dealing with rpms. Don't ever compile libs yourself of you break rpm, its not smart enough to check actual versions, just the rpm entries. With any flavor of BSD I just download the ports tree, switch to the right dir and type make;make install.

  • So (Score:5)

    by Floyd Tante ( 210193 ) on Sunday September 03, 2000 @07:40AM (#807682)

    It looks like there will be a single ports tree from which binaries for any of the BSDs can be built easily. (For those of you who don't know, ports are an automated way of downloading, compiling, and installing software).

    I imagine that this will be a huge benefit to users of things like OpenBSD, which has 400-500 ports (I think), in comparison to FreeBSD's several thousand. Each of the free BSD's already have their own binary package system (which is basically the same), but their port systems are in very different states. This will be a huge boost to BSD, and make it even easier. I hope it succeeds.

    -- Floyd
  • Maybe you should read up on BSD before posting. Its not called the BSD license for kicks.
  • Thanks.

    (o_
    //\
    V_/_

  • About Time, but a Golden Opportunity? (Score:3)

    by jasiu ( 33881 ) on Sunday September 03, 2000 @07:48AM (#807685)
    This will be a powerful step towards 'unifying' (and I mean that in a positive sense, not the negative, 'homogenize' sense) the BSD family. I'm a security freak, and I'd love to run OpenBSD... but I *need* SMP support and applications to run on top of it. My primary concern (aside from the SMP) is OpenBSD's 'borrowing' of FreeBSD's ports system. It's (IMHO) infinitely cooler than RedHat's RPMs, and I've heard it's similar to Debian's system (though I haven't used their stuff) The question is, how smooth is the transition from FreeBSD ports to OpenBSD ports?

    If this could become a reality (meaning that a package is a package is a package, on all BSDs) it would also make life much easier for those admins who need to work heterogenous environments.

    The concept of bringing OpenBSD's security scrutiny to the BSD community at large appeals to me. In fact, this could concievably be a rather powerful tool in the battle for Open Source:

    Basically the idea is to create some sort of standards body / code review group, operating independently of any one (free) OS but ideally with input (at least a person or two) from each OS community. This group would check code against portability criteria, stylistic standards, security checks, etc. Heck, you could even have submitted code ranked in these areas.

    Once examined, the (formally, legally) Open Sourced code could be put into this central repository (hint: here's the connection to the UniPort thing the post is talking about) and packaged in such a way for standards bodies (maybe an interoperability group, for example) to examine them, ports groups to package them, yada, yada.

    This is a rather rough-hewn idea; got any suggestions for it?

    Oh yah, to mail me.... sed -e 's/sp.*am\.//g'

  • I love openbsd, but the task of keeping it up to date seems a little more daunting then with my favorite linux distro (debian).

    BSDs could only benefit from a packaging tool the likes of apt. Yes the ports system is good, but nothing beats apt-get install xyz.

    What I'd really like to see in both debian and BSD is a way to snag source from a trusted server and have it built on your machine. Yes apt-get source install xyz tries to do this, but fails miserably if your machine doesn't include the necessary devel files. It would be great if apt (or another tool) would check your machine for necessary libraries/headers and if they were not available would download appropriate files and build them too, perhaps in a special directory so there not intersperced with the rest of your system, just set aside to build further packages.

    Why bother writing software when I can get some communist hippies to rewrite portions of the code at no cost to me. Life is sweet.
    -Anonymous Coward

  • ``...the ports tree should be the same for all BSDs...''

    Sorry to say that I don't think that will ever happen. Compare FreeBSD and OpenBSD for example. OpenBSD may have the same apps, but they've been thouroughly audited for security. Unless all *BSDs decide to adopt a similar philosophy as far as security is concerned, then we don't have much hope for that, now do we?

    Seriously though, is it really that hard to cd /usr/ports/whatever and do a make && make install? Is it really that hard to find the correct directory? I've never had a problem with it, then again that's just me...

    (o_
    //\
    V_/_
  • .tgz's are used to package the various OpenBSD programs in binary form (which are only a few big generalized packages) but tarballs can't do everything in binary packaging.

    The advantages to package management I've seen are:
    - pre/post-install/removal scripts (tex stuff needs to update the hash, sshd needs to get started after install, etc.)
    - file verification (rpm can do this with rpm -V, does checksumming, etc on all files)
    - upgrading; if you install a new version of a program it should be smart enough to know whether or not to overwrite your config files which may be important, i.e. for linux upgrading LILO shouldn't overwrite lilo.conf
    - dependencies/conflicts, which sometimes get annoying
    - provides (in Debian, for example, packages can recommend www-browser, which is provided by lynx, netscape, chimera, etc.)
    - previewing; before installing a package you can get version info, descriptions, etc. and yes you could make a simple script to make tar display the file /usr/share/doc/<package-name>/README but this isn't much functionality here.

    I do agree that .tar.gz is great especially because of the excellent functionality of GNU tar, and I agree that it's the most cross-platform solution (what unix doesn't have at least some kind of tar??) but this was not designed for such complex packaging as .rpm, .deb, and the others.
  • I also wonder what packaging systems it wil be based off of; will it be like RPM with lots of functionality but confusing or absent categorization (my RPM databases always turned into one package per category because I'd install mandrake or SuSE packages on top of RedHat), or will it be like .deb with a simpler style?

    There is already a package system. It is something like Red Hat, but there are no categorizations (at least in the OpenBSD version; I really only have some experience with it). You can check out the (in no particular order) OpenBSD man pages [openbsd.org] and port info [openbsd.org], the FreeBSD port section [freebsd.org] of the FreeBSD handbook [freebsd.org], and the NetBSD pkgsrc info [netbsd.org]. Reading those pages should give you more information about BSD ports/packages.

    -- Floyd
  • Yes, one of the main reasons why I don't use OpenBSD on the matchine that is both server/workstation is the lack of apps.

    Well, if the ports aren't enough, you can install the Linux and/or FreeBSD compatability(sp?) systems.

    Though as an Internet server, I think most people will find any BSD to have more than enough available software. There's not so much desktop stuff available for OpenBSD pre-compiled, but there's nothing stopping anyone from compiling stuff themselves, though I certainly wouldn't want to recompile GNOME, KDE, XEmacs and mozilla on my P133 :)

    -- Floyd
  • - As well as being able to easily list the contents of a package (e.g. "rpm -ql ..."), it would also be useful to be able to list the configuration files which would be changed.

    - At the least, when configuration files are edited, the edits should be commented, the comment including the package ID and the date of the changes, and perhaps a closing "end-of-changes" comment. If possible, lines should be commented out, rather than removed, from config files.

    - Better than the above, but more complex, would be to store old versions of modified config files in something like RCS-style ",v" files, so that old versions could be restored more easily (and "rcsdiff"s done, etc). I know rpm saves ".rpmsave" files, but to my knowledge multiple previous versions are not saved.

    - Programs / systems to make more use of configuration directories (such as "/etc/profile.d" on Linux) so that packages can just add files to this directory, rather than having to append code to existing configuration files.

    - Binary and source packages to be closely linked - binary packages could be thought of as something akin to Java byte code, source packages as Java source code.

    - Package installation tools to allow an option for installation scripts to be viewed and edited if required (rather than just being blindly executed as root, with the security problems this causes, and the ability to trample over a special user configuration).

    - An option for "nested" package installation, so that the installation program can install all packages which a specified package depends on (needing only a directory or URL where additional package files are located). Debian appears to do this pretty well (or so I'm told - I've never used Debian myself).
  • ``(and the OpenBSD ports tree is MUCH smaller than the Net or Free (with more than 3000 ports)''

    It's smaller because the apps chosen are deemed useful somewhat secure. (Yes, they actually do throw out useless apps ... 'jive' for example ;-)) Some of us dont like a bunch of useless crap slowing down our systems.

    I agree with you that the base system is their main concern (for the main project developers) , however the port maintainers do keep up their end in regards to security.

    (o_
    //\
    V_/_

  • Ports-Collection != (Debian/Redhat)Packages (Score:5)

    by kritanus ( 9944 ) on Sunday September 03, 2000 @08:09AM (#807693)
    A few posters here don't get it. The ports-collection (package for NetBSD) has nothing (or at least almost nothing) to do with .deb .tar or .rar. It is a system to install programs on your system. So before you shout "Yet another incompatible packging-system" try to understand, that it's the opposite case here. It tries to bring three (four with Darwin) Systems together. And I hope that this project will suceed.

  • Re:Hooray! (Score:3)

    by swb ( 14022 ) on Sunday September 03, 2000 @08:18AM (#807694)
    BSDs could only benefit from a packaging tool the likes of apt. Yes the ports system is good, but nothing beats apt-get install xyz.

    What I'd really like to see in both debian and BSD is a way to snag source from a trusted server and have it built on your machine. Yes apt-get source install xyz tries to do this, but fails miserably if your machine doesn't include the necessary devel files. It would be great if apt (or another tool) would check your machine for necessary libraries/headers and if they were not available would download appropriate files and build them too, perhaps in a special directory so there not intersperced with the rest of your system, just set aside to build further packages.
    Yes, something does beat apt-install, it's called FreeBSD ports and it does everything you've just outlined -- download, build and install software INCLUDING development dependencies. Maybe its Debian that could only benefit from a tool like ports.

    I understand the general idea is with binary packages, which is fine and dandy but my question is WHY? Binary packages kind of suck, IMHO -- so many things have build-time configuration options that I've never seen documented worth a damn in other binary package formats (like RPM, for example). Then there's the library go-round, especially on Linux, that makes Windows .DLLs look like a smart idea.

    Binary packages? No thanks, ports is just fine for me.
  • Maybe, with enough attempts, someone will eventually come up with a simple packaging system that is fully compatible. Hey, at least they keep trying, though it would be nice if they tried to make it broader than just BSD ... like maybe all of UNIX.
  • So explain how to make it work on all UNIX systems, not just the big 3 BSD systems. Include Linux, Solaris, and one other UNIX of your choice. Show your work.
  • I'd also like to see some way of not only restoring the previous congif files, but restoring the whole old package. AIX has this feature; it can keep the entire old package around and if you decide that you don't like the new version, you can get rid of it.

    We absolutely need to have a way to find the dependancies. RPM sucks in this regard. Telling me that I need libfoo without any way of telling me where to find said library is worse than useless. It should be a requirement to provide a URL for all of the non-standard libraries that your package depends upon. Yes, I realize that means we need to define what are standard packages. Perhaps a central repository to define libname <-> location.

    I still think it would be convenient to have the packages install in their own, personal directory tree and set links to their exe's, libs and docs within the system directories.

    While we're at it, let's get rid of GNU info files and go to HTML/SGML/XML documentation. Let's get rid of manpages in their current format while we're at it. We're long past the days when those independant formats are useful. Trying to explain to newbies that the help files might be man, info or only available through the help menu just makes them think that UNIX is confusing on purpose.
  • But is it the very same ports tree for all 3 BSDs? And what would it take to integrate Linux, and even commercial Unices like Solaris? I would really like to see such a collection that would (or could when the platform specific elements are included) put things on all different Unix class systems.
  • How come the only OS's that seem to have ports are all BSD-based? What's keeping somebody from creating a ports system for Linux? It could do wonders for cleaning up the mess that RPMs, DEBs, et al have left behind in terms of piles of incompatible package management systems.

    I've only played around with FreeBSD a little bit, but the ports system was one of the coolest things I've ever seen, and a Linux version would be sweet.
    --
  • Why limit it to just BSD? Even within BSD some differences exist. A standardized mechanism to detect the platform (and architecture where appropriate) which is modular should allow even Linux and commercial UNIX systems to have these ports (where someone is willing to do the work to add the platform specific component, which in most cases should be a few simple options).
  • A tgz package can include an install script, and even an uninstall script.

    A tgz package can include an md5 checksum file which have the sums for each individual file in the package except for the checksum file itself.

    Upgrading and changing config files is something that should be specific to the program being installed. A packaging system shouldn't try to handle it, just accomodate it by having a standard place to identify the version so it knows it is upgrading. Sometimes config files do need to have newly required items added, or even whole reformatting (and uninstall has to format backwards).

    RPM's way of handling dependencies was a failure because RPM itself could not accomodate every instance of needing to install something. I needed to install stuff before any RPM was available. RPMs are complicated to build compared to a TGZ, so software often doesn't originate in RPM.

    Generic dependencies would be cool, but the whole system needs to be able to handle establishing dependent relations even if the program is installed from source (i.e. go look and see if the friggin library is actually there, and let me install the required library afterwards if I want and still make the dependency come out right).

    A chroot option on package install mught help.

    I do believe the KISS principle should apply to ports and packaging, while still getting great functionality out of it.

  • Whatever packing is used, it needs to be kept simple. RPM isn't. I don't know the inner details of .DEB yet (since the Debian system can't be installed without either a floppy drive in your machine or downloading/buying a fullblow ISO/CD).

    My experience with RPM tells me it is a failure. The reason is that RPM was not simple enough for it to be the ORIGINATING format. Someone has to take a source package and convert it to RPM (or apparently to DEB). THIS is the failure because that step introduces a distribution latency, as well as a filtering effect (not all programs get converted).

    The proper format for packaging would be one which is JUST AS EASY to build as building a TAR file and compressing it. Right now, the TGZ format meets that requirement. So maybe it should be the starting point to add the additional needed features.
  • - It should list WHAT CHANGES will be applied to the configuration files AND allow me to install w/o them being changed (leave behind the document that explains what needs to be changed and let me do it).

    - How about configuration files that are version specific in their names with symlinks pointing to the currently active version (likewise with the executeable).

    - I don't want my C code to be treated like Java.
  • I'm a security freak, and I'd love to run OpenBSD... but I *need* SMP support and applications to run on top of it.

    SMP support is available for sure on FreeBSD, you might want to check out this link to the FreeBSD hardrware FAQ [freebsd.org] to read more, i don't know if FreeBSD is an option for you?

    The question is, how smooth is the transition from FreeBSD ports to OpenBSD ports?

    In my experience, very simple, i haven't had any trouble at all. But anyway, this new ports proposal would unify the lot and make it even simpler :)

    Fross
  • It takes a lot of work setting up a ports system, and nobody has tried it yet. I can't see where it would clear up the RPM, DEB, SLP problems - it would just add another competitor.
  • A PATH of package/port site locations, and the ability to redirect to another site when a package isn't at a site, could be a useful means to find the needed dependency. Then an interactive install can bring up a menu/choice of where to install from (if desired). A non-interactive install can have a site preference list.

    I do agree that having each package in its own tree would be useful. Piling all the executeables into a "bin" directory has always made things difficult (though it certainly makes commands go faster). Some ideal solution to that would be great. Possibilities include piling in symlinks, or PATH entries like /opt/*/bin.

    And I also do agree WRT to those annoying info files. That system was always a pain, and the usual culprit was dependencies or not being able to find stuff. HTML should be written to be at least functional in lynx.
  • What library go around? Windows .DLLs are part of the problem of why stuff crashes in Win95/98/NT/2K systems where the wrong DLL is present. In Linux you can reference libraries by name, name and version, or however you like. Then you can have multiple versions there ready to use at run time.

  • I'm a security freak, and I'd love to run OpenBSD... but I *need* SMP support and applications to run on top of it.

    Whoa there I can't think of one security-minded application of OpenBSD that needs SMP. Run it as a firewall? 233MHz +64MB of RAM is plenty for NAT and IPF. Single-proc systems have all of the horsepower you'd need for "security-freak" apps that OpenBSD excels at. It's not really meant to be a desktop OS first.

  • Source vs. Binary (Score:3)

    by SecretAsianMan ( 45389 ) on Sunday September 03, 2000 @09:25AM (#807710) Homepage

    A unified BSD ports/packaging system is definitely a good and logical step forward. Despite the differences in focus of each BSD flavor, I believe that a unified ports tree will stop a lot of duplication of work. If this goes down, we BSD people should hope to see more ported apps with less failed builds.

    One thing I must mention, though -- and since all I know about is Free BSD, this might not be true for the other BSD distros. There need to be both source and binary packages available, and there needs to be only a MINIMUM amount of disparity between the two. Currenly, there is too big of a difference in what you can get with the ports tree (source) and the packages collection (binaries). The way applications are named and organized is different in either place, and the selection differs, too. Any unified ports tree needs to make it simple to choose whether you want to build from sources or just install binaries -- and offer both choices for each app unless licensing issues would prevent it.

    Being a programmer, I prefer to build most of my third-party apps from source. However, I might not want to wait for some of the bigger ports (kde2, for instance) to build. Installing binaries should be equally accessible.

  • ...the Debian system can't be installed without either a floppy drive in your machine or downloading/buying a fullblow ISO/CD...
    It depends on the architecture. Debian/SPARC, for example, will TFTP a boot image just fine and do a net install. Or, on the PC, you can make any kind of CD image [debian.org] you want (including just a minimal setup installation). There's also information on a variety of installati on methods [debian.org] available for i386.

    Just thought I'd point this out. ;)

    --

  • Re:Hooray! (Score:3)

    by spankenstein ( 35130 ) on Sunday September 03, 2000 @09:47AM (#807712) Homepage

    Why binary... slow machines!

    For many years my only box was a 75Mhz pentium. Compiling anything took forever on this box so... binary packages were good.

    Also... with something as intelligent as the Debian packaging system, I don't need to worry about dependencies and compiling every little thing that package foo needs. One good example is GNOME or KDE. I actually have things that I need to get done other than watch my machine compile a desktop environment all day.

    I have nothing against compiling from source, and I do really like the FreeBSD ports. I also like typing apt-get source foo then running dpkg-buildpackge and having a .deb with all the dependencies in tact.

  • > Whatever packing is used, it needs to be kept simple. RPM isn't. I don't know the inner details of .DEB yet

    Makes RPM look simple, that's what. It requires a whole *directory* full of miscellaneous spec type files, and about 4 different programs to build. Nightmarish, really.

  • No Big Deal - BSDL (Score:3)

    by Christopher B. Brown ( 1267 ) <cbbrowne@gmail.com> on Sunday September 03, 2000 @10:09AM (#807714) Homepage
    pYou need to separate this into two pieces:
    • The Ports tools would need to use the same license, namely the BSD license.

      This is no big deal, as this is very likely the case already for the differing versions for the differing BSD variations.

    • Individual packages would retain whatever license they already have.

      Note that there are Ports for all sorts of GPLed software and such.

    The point here is that what licensing is crucial is that of the package tool, and not anything more than that.

    By the way, it is eminently likely, and should be blatantly obvious to anyone that does a modicum of research that the system proposed is to be based on the BSD Ports system, which is neither particularly like RPM nor is it greatly like dpkg. (Although the differences betwixt Ports and dpkg are a bit less dramatic, as the Debian project has a similar interest in having "somewhat centralized public access to the source code tree."

    Ports involves a "central" Makefile that knows how to look up source code for individual packages. It is essentially based on the philosophy of pulling sources for software, wrapping around it a Makefile and any patches needed to resolve differences between pristine sources and the code that is needed to make it compile and run on the system in question.

  • Slackware has traditionally had somewhat closer ties to BSD than the other Linux distributions, and it has long eschewed the notion of producing "binary packages" that were any more sophisticated than being basic tarballs of the binaries.

    Hooking up Ports to Slackware would have the merits that:

    • While it means there's "something more than just zcat whatever | (cd / ; tar xvf -) " to install new software, it is still very much "in the traditional command-line Unix philosophy"
    • It would mean that things like the long-standing Metafont bug in the TeX installation might get fixed in the central CVS repository, perhaps by someone not the slightest bit associated with Slackware.
    • It could make it a lot easier to get a bunch of additional software installed on Slackware; no need to install it all by hand.

    Note that this doesn't contribute to "cleaning up" any of the "mess of incompatible package management systems;" that is something that is not going to be changed quickly, if ever.

    By the way, for "flip side," there was a proposal at one point to build a FreeBSD kernel with a Debian user space... Definitely different strokes!

  • Actually if the Ports portion works like OpenBSD, then it would be easy to "port" this part over. The Ports just download the source, apply some patches that are specifc to the OS, compile, install, and log the installation. Assuming the source compiles on the the machine, the "Ports" would work.

    The Package portion would be harder because they are Binary, and since Linux doesn't have a "BSD Compatibility Mode", this ain't gonna work. Though Linux might be able to hobble through it, I don't think Solaris or IRIX could use the binaries. So the only way to accomplish this part would be to make completely different binaries for each target OS. Too much, too soon. Ask later when(if) this system gets picked up on the BSDs.

    The reason it's BSD only is because the BSDs are so close to each other with binary compatibility, unlike IRIX, Linux, and Solaris.

    So to answer your question: Ports would work, Packages would NOT(yet)

  • OpenBSD may have the same apps, but
    they've been thouroughly audited for security.


    This is generally only true for those ports in the ports/security tree. Most of the others haven't been havily audited. Certainly no more so than for FreeSBD's system. There are exceptions on both sides.

  • Your argument would be equivalent to dismissing RMS and GNU based on the fact that there is no the FSF has produced no GNU kernel.

    4 OS compatibility is certainly better than 1 OS compatibility and when it works, may attract others. What's so wrong with that?

    DB
  • This sounds like a great idea. Since this is still very early on in it's development, I'd like to suggest a feature that I don't think is present in any of the current ports systems: support for cross compiling ports. The NetBSD pkgsrc system has several cross compile packages, but using them to build packages for other architectures is very tricky. I made some modifications to bsd.pkg.mk (available here [cmu.edu] if anyone's interested) to try to cross compile wterm for netbsd/mac68k on a netbsd/macppc machine, and it mostly worked (had issues linking since the cross linker I had only supported static linking, though everything did compile fine).

    There are some issues to be worked out as far as whether dependencies need to built for the host or target architecture, but I think it would be a very useful addition since all of the BSDs support more than one architecture (well Darwin can build for x86 even if it can't actually be booted on x86 machines yet...) Speaking of Darwin support for fat binaries would be interesting, too.

  • Yes, something does beat apt-install, it's called FreeBSD ports and it does everything you've just outlined -- download, build and install software INCLUDING development dependencies. Maybe its Debian that could only benefit from a tool like ports.

    Frankly, Debian has the infrastructure in place to do this, but the developers just don't seem interested. Source packages have a "Build-depends" field that says which packages are needed to build them, so this would be a matter of downloading a source package, recursively satisfying its build dependencies from source, and then building it. I bet this could be written in pearl in a few hours.

  • it would be nice if they tried to make it broader than just BSD ... like maybe all of UNIX.

    One of the features mentions Solaris.
  • There's such a thing as a source rpm. Every binary rpm must have a corresponding source rpm. If you want to build something yourself, all you need to do is download the .src.rpm, install it, and modify the spec file. It's pretty easy to locate the configuration options. And after you modify the spec file, you can build a new source rpm from it. Then you can install your modified binary package on several other computers without having to recompile on each one.

  • A Newbie Perspective (Score:4)

    by Metrol ( 147060 ) on Sunday September 03, 2000 @12:14PM (#807723) Homepage
    I started my journey into the world of Unix OS's with RH 6.0, then upgrading to 6.1. The first couple of rpm's I dealt with really impressed me with how it handled stuff. Then, as many have mentioned, I started running into the enevitable dependency problems. Especially true with Gnome based apps. As time wore on I also noticed that it was becoming increasingly difficult to locate the latest version of an app as an rpm. The GUI rpm tools that were supposed to go hunt down the latest stuff off the web consistantly pulled back far older versions, and often pointed to dead web and FTP resources. I always loved running into the RedHat FTP server in a 24/7 overloaded state. So here I was manually compiling and install stuff outside the rpm database. Completely defeating the purpose of having package management.

    One hard drive crash later I decided I'd try out a different distro. After a couple of days mulling it over I decided instead to try out FreeBSD. After figuring out how to pull down the latest ports package I tried running a couple of them. I can't begin to express how impressed I was with this. It appears to consistantly have the very latest stuff, it deals with the compilation and installation for me, and enters the app into the package management system. That, and as I watched it poll a list of ftp sites looking for an active one, then also went about pulling in required libraries my jaw just dropped.

    As impressed as I am with how FreeBSD handles apps, there is one aspect I fealt wasn't quite as strong as rpm. rpm's provide a fairly elegant method of udgrading applications that appears to deal with the issues of cleaning out the old app and getting the new one in there. FBSD on the other hand has you go with a process of deinstalling then reinstalling which seems to be prone to all kinds of nasties.

    For example, when trying to deinstall a library that other apps depend on the system will stop ya in your tracks. Just trying to install over an older app puts both versions into the database. I'm still fighting a wrong turn I made when upgrading XFree86. I'm certain that a more experienced user would have danced right around the probs I had, but it seems evident that there is room for improvement here.

    As it is, I'm far happier with the dealing with apps on FreeBSD than I ever was with RedHat. I genuinely hope that this new project can help better streamline this process. Furthermore, it seems that the various Linux distros could greatly benefit from something like this as well.
  • > Commander Gordita. Love it.

    I wonder how many people have made the connection that gordita is Spanish for 'little fat girl'. Somebody at Taco Bell's marketing department really laid an egg on that one. ;-)

  • Re:How about .tar.gz? (Score:5)

    by Metrol ( 147060 ) on Sunday September 03, 2000 @12:41PM (#807725) Homepage
    But is it the very same ports tree for all 3 BSDs?

    Nope. That's the reason for starting up the Open Packages project in the first place.

    And what would it take to integrate Linux

    Hopefully I don't screw up this description here. On FreeBSD there are two different methods for adding packages. The first is from the "ports" collection. These ports are a collection of fancy makefile scripts that have a series of expected locations of the source files, and some instructions on what to do with them, ie. configure, compile, install. These scripts also include a list of dependant packages which are used to either verify they exist, or go and install them.

    The second method of installing an app is doing a pkg_add, which is a method for dealing with already compiled packages.

    The only stumbling block I would think that a Linux distro would have in implementing this is the final stage of a port install: entering the package into the database. For instance, on RedHat it's expected that all apps will get an entry into the RPM database. FreeBSD sort of expects the same thing, only to it's package db instead. The concept of package management breaks down real quick like when more than one db is in use, since that is what is referred to for tracking dependencies and such.

    The really sad part here is that even if this Open Packages project ends up making folks wonder what was so great about sliced bread anyway, it still won't get used on Linux. RedHat isn't showing any signs of giving up on rpm's, and the same can be said for Debian's .deb packages. Too large of an installed base for both to just change gears now, and there's also a point of pride that kicks in as well. If anything, I expect the various Linux distros will most likely just hunker down further in however they handle package management.
  • That's entirely untested, though, so it might not work as I imagine.

    It does not do at all what I said.

    For example, my system has absolutely no Gnome software on it, no libraries, no nothing. If I run your command with the gnome-games package, it will download the gnome-games source, try to compile it, and fail, because the libraries and headers needed for a successful build are not already present in the system.

    The correct thing to do is to know beforehand which packages are going to be needed to build the program, build those, and then build the original package.

  • I definately would support a more standard, unified packaging system across Linux/Unix systems.

    This is absolutely a case where standardization is a good thing -- so long as it,of course, remains open-source, and as long as there are other options available. Neither of those are really a problem in this case.

    Also, if Linux wants to go consumer, it absolutely will need to standardizing in the way of system applications. This is a good example.
  • There's such a thing as a source rpm. Every binary rpm must have a corresponding source rpm. If you want to build something yourself, all you need to do is download the .src.rpm, install it, and modify the spec file.

    The problem is that this is not automated.

    I can understand the poster's complaint. I run Debian, and I frequently need to compile packages from source, enabling options that are disabled by default (in my case, Kerberos 4). Whenever a new version comes out, if I wish to update to it, I have to download the source for that, make my modifications again, and only then can I compile a new version.

    A mechanism where users specify local options that the package building system would use during the build process would be the perfect solution here.

  • I disagree. From my experience the Ports system seems a little clunky and inconvienient. Have you tried apt? apt-get and apt-cache truly are great.

  • YAY! (Score:1)

    by Lx ( 12170 )
    I really would love to have something like this in place. Every time I try OpenBSD, I say "wow, it's really nice, but it just doesn't have enough ports...". It's silly, but that's what keeps me from using the OS on a regular basis, sticking with FreeBSD instead - I don't want to run around without and package management ability, and I don't want to have to grab loads of apps that were written primarily for linux, and don't have configure scripts, and have to tweak them to run.

    As far as security of the ports, which I think Open has stopped being so strict about, I don't think it's the responsibility of the project to audit other people's code. If anything, the tree could be split into a secure and regular branches, so people who cared could just stick with secure.

    -lx
  • Right now, the ports retrieves the source tarball from a site, all the required source tarballs, and then builds them one by one. Why can't we have a binary ports system as well?

    In FreeBSD, this is the difference between a port and a package-- packages are what ports build. From the FreeBSD Ports page [freebsd.org]:

    For most ports, a precompiled package also exists, saving the user the work of having to compile anything at all. Each port contains a link to its corresponding package and you may either simply download that file and then run the
    pkg_add [freebsd.org] command on it or you can simply grab the link location and hand it straight to pkg_add since it's capable of accepting FTP URLs as well as filenames.
    pkg_add will download and install dependencies, too.
  • Having problems like this and learning what you did wrong is what makes you an experienced user. "Improved" package management systems, like rpm, offer zero contribution towards making the end user any better at understanding anything beyond the flags required to get their package manager to behave.

    In one respect I agree with the sentiment of your post. Yes, when things go wrong this provides for a learning experience not available when all things go right.

    On the other hand, as an end user I'm not the least bit interested in getting that involved with the mechanics of gettings applications on and off a system. My primary focus is on using and learning that application just installed.

    For example, on my NT box when I run a Setup.exe I fully expect that thing to handle everything in the process of getting that app on my system, possibly upgrading an older version, and adding an entry into the Add/Remove database. The port system provides for similar functionality, but could use some streamlining from what I've seen. Mind you, I see the ports collection as a far more powerful tool than what NT does, but there is plenty of room for perfecting that system.

    What would really kick butt is a GUI front end similary to GnoRPM to handle administration of ports and packages. A little something that could deal with putting together the proper CVSup files for port updating, front end the various pkg commands and such. Essentially give a pretty face to this wonderful infrastructure. That alone would save about 2 days worth of learning curve.

    I'm going to go hide now, as I can see a rather angry mob of CLI folks starting to form.
  • What's wrong with just using rpm or dpkg? Not invented here syndrome? If there's something wrong with rpm or dpkg, why don't they just contribute to these existing projects instead of reinventing the wheel yet again?
  • I guess if you'd check history, you would discover
    that the BSD ports collection was there before
    rpm of dpkg.

    - Hubert
  • FYI: pkgsrc people of the NetBSD project are
    participating in the "unified packaging system"
    project, and given that NetBSD's pkgsrc is already
    being used on Solaris and Linux (besides NetBSD :)
    this may set a good direction.

    - Hubert
  • FYI, the NetBSD Packages Collection (which is derived from the FreeBSD ports collection) runs
    not only on NetBSD, but also on Solaris and Linux.
    I don't think we have may users in Linux-land by now, but why not try & make some feedback? :)

    Folks on tech-pkg@netbsd.org should be able to help you out...

    - Hubert
  • I looked around openpackages.org but I can't find a link to the mailing list. Did I miss something?


    --
  • The Ports just download the source, apply some patches that are specifc to the OS, compile, install, and log the installation.

    That last bit is the clever one though. How do you "log" the installation properly on a platform that also expects a seperate db to be updated? RedHat, for instance, is utilizing a completely differnt database for logging installations from how any of the BSD's do it. This splinters further when you start getting into Debian and other managers.

    It just occured to me a possible solution for this. Right now a FreeBSD port goes through and handles all the downloading, compiling, installing and registering. What if instead of going through the installation process, it went and created an RPM file from the source. At that point it could simply make a call to rpm to handle the last two stages, installation and registration in the package manager. Uninstalls and upgrades would continue to be handled with rpm, and fresh installs from a ports collection.

    I've never built an rpm file, so I have no idea how automated this process can be made. In theory it sounds like it could be made to augment rather than replace existing package managers. Perhaps this Open Package project might want to consider a more ambitious goal? That, or I don't have a clue of what I speak of, which is most likely the case.
  • You'd have to know the history behind NetBSD and OpenBSD to understand why the two aren't the same. As for FreeBSD...all three share the same lineage, but branch at vastly different parts of the BSD tree. Suffice it to say that OpenBSD and NetBSD are the closest with FreeBSD somewhere in a land of it's own.
  • I started my journey into the world of Unix OS's with RH 6.0, then upgrading to 6.1. The first couple of rpm's I dealt with really impressed me with how it handled stuff.
    [...]
    After figuring out how to pull down the latest ports package I tried running a couple of them. I can't begin to express how impressed I was with this.

    I can't help it...

    You would love Debian. Imagine RPM with a centralized, authoritative package repository. Imagine never having to search for dependencies again, because they are all right there on the same server. Imagine using a program (we call it apt-get -- ahh, the sweetness in that name!) that automatically downloads and installs the newest (run "unstable" and it's the truth) versions of whatever software fits your fancy.

    We call it Debian [debian.org].

    --
  • -Not enough good Mirrors : What network are you hooked up through? I can honestly say, anytime I have problems getting to a mirror, it is because of my network provider, not the quality or quantity of the mirror sites.
    -Fetch is broken (broken/truncated files) - See 1st question.
    - Compile from sources only - /stand/sysinstall has a binary package install utility built in.
    [Shrug] I don't see what your beef is.
  • You would love Debian.

    From what I've read about it I just might. As things are now, I've got two boxes here at home to work with. One of them runs NT, and until I see some serious HTML development tools (ie. Dreamweaver, Homesite) either get ported or something equivalent it'll stay an NT 4.0 box for a long time to come. My other box is intended to simulate a real world web server, and since the web host I utilize runs FreeBSD it seemed like a good choice for me.

    Like I said, I'm still pretty new to Unix as a platform in general. As much as I like to take a tour of the various distributions of Linux, it's probably a lot wiser for me to hang tight with what I've got running and learn it well. I do intend to take a tour of the rest of the spectrum as time and money permits. One thing I have learned is that it can take months of mucking around before you can really appreciate, or dislike, the kinds of tweaks that go into an OS.

    because they are all right there on the same server. Imagine using a program (we call it apt-get -- ahh, the sweetness in that name!) that automatically downloads and installs the newest (run "unstable" and it's the truth) versions of whatever software fits your fancy.

    To more directly respond to your suggestion though, isn't Debian's system part of the over all problem? Not it's technical merits, but rather the fact that it's only for Debian and its child distros? Seems that this very kind of thing is what Open Package is trying to address for the BSD family of OS's. I would hope that the end game here is to eventually get to a point where a developer can issue a single file from their web site that can easily port itself to whatever platform is running. As cool as Debian is, I don't see it moving things in that direction.
  • But how is this not automated? You download a .src.rpm, do an "rpm -i" on it, modify the spec file in /usr/src/redhat/SPECS. And then you just do an "rpm -bb" to build a binary package, or an "rpm -bs" to create a modified source rpm, or "rpm -ba" to do both. The spec file isn't any harder to change than a FreeBSD ports Makefile.

    The only difference is you have to download the source ahead of time for rpm's. But any changes you make to a FreeBSD ports Makefile will need to be redone when the package gets updated anyways.
  • There's a reason it's called the BSD ports system. This argument is like saying that RPM's are bad because they don't work under Irix and VMS.

  • conflict detection (Score:3)

    by aanantha ( 186040 ) <ahilan_anantha@yahoo.com> on Sunday September 03, 2000 @06:27PM (#807745)
    One thing I don't like about the FreeBSD ports system is that you can install a package that conflicts with another package, sometimes without even knowing about it. For example, I installed kde 1.2 from ports a while back. Now I recently installed kde 2.0beta4 from ports. I had trouble getting kde2 to compile in the first place, so I didn't want to remove kde 1.2 . But now that both are installed, they both claim ownership to certain files. So now if I were to uninstall kde 1.2, it would delete kde2 files as well.

    I see this happening a lot with library packages. You might have a previous version of gtk installed, for example. But then when you compile a new GNOME application, it'll trigger the compile and install of a new version of gtk. But the old one doesn't get uninstalled. It just installs on top of it. And then there's no way to clean out the old one after the fact. I end up deinstalling both, and reinstalling the new one. I think that at the very least, packages should all attempt to uninstall earlier versions before installing.

    With FreeBSD ports, you can find out what files are part of an installed package. But you can't go the reverse direction. You can't ask what package a file belongs to. RPM can do this. I suppose that's how RPM prevents packages from clobbering each others files. And somehow RPM can do this without making the install process slow.

    Redhat Linux's RPMization of everything does make things rigid. But there are some advantages. It's mostly easy to upgrade to newer versions of the distribution. Since the Redhat installation just consists of bunches of installed rpm's, you just need to upgrade every package. Once I had a Redhat 6.1 upgrade installer break on me. But all I had to do was do an "rpm -Uvh" on each of the rpms to upgrade from RH6.0 to RH6.1 .

    But in FreeBSD, an upgrade install (or make world) just dumps stuff on top of whatever you already have. So shared libraries and programs from the earlier install get left around.
  • To more directly respond to your suggestion though, isn't Debian's system part of the over all problem? Not it's technical merits, but rather the fact that it's only for Debian and its child distros?

    The unity of the Debian distribution depends on the ability of the Debian developers to issue and enforce policy. Every single package on my system installs documentation into /usr/doc. The naming and versioning systems are standardized, so there's no 3.2rc3 vs 3.20-4 problems. The installation scripts depend on things being laid out the way the Debian packages lay them out. It's the price of the cohesion you get with Debian.

    I'll be interested to see how this OpenPackage aims to overcome this. Create and enforce policy, like Debian, or what...?

    --
  • Yes, you're missing something. Although BSD packages are distributed in files ending with ".tgz", they do have internal structure -- there are certain files in certain formats that must be present in the tarball, or it is not a package.

    --
  • But how is this not automated?

    It's fairly obvious, isn't it? I'll highlight it for you:

    You download a .src.rpm, do an "rpm -i" on it, modify the spec file in /usr/src/redhat/SPECS. And then you just do an "rpm -bb" to build a binary package [...]

    This is the problem. You have to manually make modifications.

    With a ports system, you throw a patch into the patches directory for the package, and it gets automatically applied to the source tree in the normal build process.

    The only difference is you have to download the source ahead of time for rpm's. But any changes you make to a FreeBSD ports Makefile will need to be redone when the package gets updated anyways.

    Unless you do as I say above-- you drop a patch into the patches directory for the port.

  • Funny that you claim tarball packaging can't work. It works just great on my slackware system - I am FAR happier with it than I was with .rpm.

    The BSD ports collection does look very nice though, and I would love to see something like that on slack.

  • Yeah, like the other poster said, try Debian. Its package management system is simply amazing. No other Linux distribution (well, except the ones based on Debian ;-) come even close. Heck, no other OS has anything like it, period!

    Imagine a system, similar to FreeBSD's ports, that:

    1. Works with binaries. You can download and install binaries instead of having to wait for it to compile. You can also request to get source though, and compile it (just like in FreeBSD).

    2. Figures out dependencies auto-magically and downloads all the required libraries. For example, if you say "apt-get install ssh", apt will figure out that ssh depends on libssl, libwrap, libz, etc. It will also figure out that ssh *conflicts* with ssh2, ssh-nonfree, ssh-socks. That is, apt will determine not only dependencies but also conflicts. So, (unless you force it), it will not let you install sendmail, qmail, smail, and exim at the same time.

    3. *Handles upgrades*. "apt-get upgrade" will upgrade the packages you have installed. And no, you don't need to do deinstall and reinstall everything. Apt is smarter than that. I guess it's called apt for a reason ;-)

    (btw, could any Debian developer tell me what apt really stands for?)

    ___
  • Actually I disagree with this. I have used both the openbsd ports system and apt-get. Although they are both wonderful tools, apt-get is by far the better tool.

    I find it much easier to add third-party packages (Helix Code mirror), even mix unstable and stable packages.

    One thing that would make ports as good as the Debian system is some way to tell me, and offer automatic upgrades when new versions are released.

    Nicholas
  • Note: I'm an experienced Debian user, so when I mention shortcomings in what follows, I do so as someone who has experienced them through 2.5 years. Debian is good, but, hell, it's not perfect. Also, in the interest of full disclosure, I've been investigating FreeBSD documentation lately quite a lot, since I plan to use it in my next workstation (sometime this month).

    [Debian's] package management system is simply amazing. No other Linux distribution (well, except the ones based on Debian ;-) come even close. Heck, no other OS has anything like it, period!

    This statement is put into doubt by the ignorance you show below about BSDs.

    Imagine a system, similar to FreeBSD's ports, that:

    1. Works with binaries. You can download and install binaries instead of having to wait for it to compile.

    Why, FreeBSD's pkg_add does this. Downloads dependencies, too.

    You can also request to get source though, and compile it (just like in FreeBSD).

    Not just like FreeBSD. The Debian support for auto-managing dependencies does not extend to source. If you don't have the packages required to build the source, it will simply fail.

    2. Figures out dependencies auto-magically and downloads all the required libraries.

    FreeBSD already does this.

    3. *Handles upgrades*. "apt-get upgrade" will upgrade the packages you have installed.

    Take a look here [freebsddiary.org]. Essentially, pkg_version -cv' is the FreeBSD equivalent to apt-get upgrade.

    The point is simple-- the philosphies behind apt and the ports trees are different, and there are many intricacies behind each. To make a fair comparison one needs to know each in depth.

    The ports tree's emphasis is on building from source, and it simply whoops apt/dpkg's ass at this. In my particular environment, I'm finding that this is a feature I could use-- I build a few Debian packages by hand frequently to enable features, which I see could more easily done in FreeBSD.

    I've yet to try FreeBSD, but I suspect Debian's automatic configuration of packages is superior, and will get even better as more and more packages are made to use debconf. But once your system is configured appropriately, this is no longer an issue.

    Also, I think FreeBSDs development model (e.g. the base OS/ports split) lends itself to more frequent, high quality stable releases for the basic system, and fairly up to date additional packages. You can't get this combination in Debian-- you either run stable, where you get a well-tested system with out of date software, or unstable, where you are on the bleeding edge. (I run both versions in two different machines).

    In short, FreeBSD, from what I've researched, is a very good system, which I suspect I will much prefer to Debian (and this comes from a 2.5 year Debian user).

  • (btw, could any Debian developer tell me what apt really stands for?)

    Advanced Packaging Tool

  • Debian's apt will give you the best of both worlds:
    Automated downloading and upgrade, just the same great dependency management as FreeBSD, and packages upgrades are a breeze.
    Moreover, Debian packages are tightly integrated with each other and provide sensible default configuration files...
  • I'm not sure what kind of patches you're talking about. I was talking about build configuration changes. In which case you'd either be modifying an RPM spec file or the one BSD ports makefile. The FreeBSD patches directory is only for patching the actual source in the tarball. Those patches always need to be updated for each new software release. RPM can also automatically apply patches as well, but you need to specify the names of each patch in the spec file. The patch files get bundled together with the main tarball in the source rpm.
  • You would simply have to put the relevent information into the RPM Database, which IIRC is just a text file. You can even do this manually if you install something from a tarball. (RPM's can sometimes be horribly out of date, as anyone who has tried to use a 2.4.0 kernel on a Redhat system will atest to.)
  • For example, when trying to deinstall a library that other apps depend on the system will stop ya in your tracks. Just trying to install over an older app puts both versions into the database.

    Use pkg_delete -f

    which allows you to force the removal of a package if you are sure you know what you are doing.

  • autoconf (Score:1)

    by dcs ( 42578 )
    Well, now, that's an interesting piece of software. Thing is... autoconf works for the platforms the author configured it too. Lately, it is an automated source configuration system that generates the appropriate header files and defines to compile stuff under Linux. :-)
  • Yes the ports system is good, but nothing beats apt-get install xyz.

    pkg_add -r xyz? It's smaller. :-)

  • Yeah, Not Invented Here syndronme is a drag. I mean, why did they have to invent rpm and dpkg instead of using FreeBSD ports/package system?

    Well, the OTHER BSDs did not make this mistake, and adopted the ports/package (though ports is called packages on NetBSD, since they already used the word "ports" for something else). But since they are different, the _content_ of the ports tree is different. You can't use the FreeBSD one on OpenBSD. That's what they are unifying.
  • I think that this will be great, but won't there be problems with some ports not being available to MacOSX because it uses that Aqua thing (i intend on using MacOSX on my iBook, because i believe that it will be more stable and use the power more efficiently, than the currently available Linux;s) This is not to bag the Linux distros that are currently avail, after all Apple do have ALL the cards with regard to info about the hardware.


    .sig = .plan = NULL;
  • The BSD ports system does that. Well, it actually uses variables that can be overridden to determine stuff such as where things are getting installed, but, by default, everything gets installed in standarized places. See man hierarchy.

    The plan is using the same ports tree to ALL BSD.

    Frankly, there level of cluelessness of Debian people about ports/package is mighty impressive. There is only _one_ thing that Debian does in an automated fashion which ports/package doesn't which is upgrade.

  • > Whatever packing is used, it needs to be kept simple. RPM isn't. I don't know the inner details of .DEB yet
    Makes RPM look simple, that's what. It requires a whole *directory* full of miscellaneous spec type files, and about 4 different programs to build.

    That's not true. RPM needs one spec file and one commaned (rpm -ba foo.spec) to build a package.

    - Aidan

  • 'apt-get install xyz' is somewhere better then 'pkg_add -r xyz' ?

    One major benefit is that apt-get install "xyz" works fine, but pkg_add "xyz" bombs unless I use pkg_add "xyz-1.tgz". In other words i need to know the entire file name. Which is something I don't care to remember. I just trust apt to keep everything up to date.

  • >Linux as one kernel with lots of userlands

    If it is ONE kernel, then things like PICK should work on *ANY* Linux distro. PICK only works on a few.

    The linux kernel as shipped on CD's from the 150+ linux vendors is not ONE. It is one+small changes that break compatibility.

  • Just one issue with your assertion that different packaging systems == different dbs. There's no reason why software can't be written to convert from one style to another. There is the 'alien' package for debian which does exactly that for RedHat, Stampede, and Slackware packages. Unless there is a fundamental difference in the underlying system, most packages should be translatable. (unlike English idioms which usually do not translate into other languages well, or at all) Since the Linux distributions share a lot in common, this shouldn't be a problem. Likewise with the *BSDs. Whether a package translator could work between Linuxes and BSDs is up for speculation however.
  • Correct. I was referring to the byzantine build system of debian.
  • *cough* SOLARIS *cough cough*

    Just to quote from the features section of openpackages.org:

    Support for Solaris (it is being used!)
  • One of the small hurdles pointed out on the openpackages.org page is the lack of an equivalent utility to FreeBSD's fetch(1) for NetBSD or OpenBSD (or presumably Darwin / Mac OS X). The solution is pretty obvious - port fetch and the small amount of underlying infrastructure - but the benefits will be great.

    For the Linux people who haven't tried out FreeBSD yet, fetch is a tool something like wget that takes URLs to retrieve a resource noninteractively. Having a good tool like this can be indispensible for more than just building a package system, and fetch is a very good tool, with useful options and workarounds for lots of cases that come up in retrieving files by FTP or HTTP. I've made use of it elsewhere and solved problems that might have required a C or perl program with just a shell script. Having it on Mac OS X and OpenBSD will be a boon. The only things it doesn't currently do (that I could sometimes use to work around braindamaged web design) is the ability to set the Referer and User-agent header values, as http_get can do. Perhaps those'll be added when it's ported.

    Oh yeah, the rest of the unified packaging system will be cool too. ;)
  • All the BSD command line stuff and background daemons would probably be easily maintainable. Supposedly, Mac OS X uses a FreeBSD 3.x based server on top of Mach. X libraries are portable. You can probably compile all the X11 programs (clients) you want to, if you wanted to install X libraries. They won't be any use without an Xserver, of course. You'll need that to run any X11 clients. Tenon will offer an X server that can run within the Mac OS X Aqua GUI (i.e. within Openstep).
  • FreeBSD's ports/pkg system:

    1) works with binaries. you can use pkg_add binary_package to install a binary, and to build a binary package, just 'make package' from the appropriate ports directory.

    2) figures out dependencies auto-magically and downloads all the required libraries.

    3) doesn't handle upgrades nicely, you have to do a pkg_delete foo ; pkg_add foo combination to upgrade.

    lastly, apt stands for 'advanced package tool', something that 'man 8 apt' would've told you.
    ----------------------------
  • handles upgrades quite nicely.

    pkg_version -l '<' -c > update

    produces a handy upgrade script.

    ----------------------------
  • I've found that often (but apparently not always) make tries to make all the dependencies for which there is currently no build directories.

    Roughtly, if I build X (which takes forever), then delee the source (for the space), and then build xload, I'll end up with the machine making X again. I'm sure there's a simple solution, but I haven't found it yet . . .
  • For example, when trying to deinstall a library that other apps depend on the system will stop ya in your tracks.

    Well, last Saturday I got tired of Qt without GIF support. I know gifs suck but when the web is still 50% gif based, it makes kfm pretty lame for browsing.

    So I went into /usr/ports/x11-toolkits/qt145 and did the following:

    make deinstall
    make extract
    (fiddle with the Qt configuration)
    make install

    Done! No problems. The existing KDE apps were unaffected. I didn't have to reinstall anything other than Qt.
  • Oh yea! That *is* sweet. Put cvsup in your cron file and you will be current each and every morning. With a slight more amount of effort, you can have cron mail you for any new version of your currently installed ports.

Slashdot Top Deals

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Close