Slashdot Mirror
Unified BSD packaging system?
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.
The question is is the standard so good that Linux distro's will adopt it as well?
-- Sometimes you have to turn the lights off in order to see.
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.
"If I have seen further than other men, it is by stepping on their glasses." - Michael Swaine
That is how the BSD's distribute files (source is the preferred). This is more concerning the package management.
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?
.deb with a simpler style?
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
# debian/rules
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.
Only the State obtains its revenue by coercion. - Murray Rothbard
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
-- Floyd
Maybe you should read up on BSD before posting. Its not called the BSD license for kicks.
Only the State obtains its revenue by coercion. - Murray Rothbard
Thanks.
//\
(o_
V_/_
Windows2000: Where do you think you're going today?
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'
cat email | 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...''
/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...
//\
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
(o_
V_/_
Windows2000: Where do you think you're going today?
.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.
/usr/share/doc/<package-name>/README but this isn't much functionality here.
.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.
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
I do agree that
# debian/rules
- 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)''
... 'jive' for example ;-)) Some of us dont like a bunch of useless crap slowing down our systems.
//\
It's smaller because the apps chosen are deemed useful somewhat secure. (Yes, they actually do throw out useless apps
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_/_
Windows2000: Where do you think you're going today?
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.
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.
now we need to go OSS in diesel cars
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.
now we need to go OSS in diesel cars
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).
now we need to go OSS in diesel cars
(n/t)
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.
now we need to go OSS in diesel cars
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.
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.
Washington, DC: It's like Hollywood for ugly people.
This is no big deal, as this is very likely the case already for the differing versions for the differing BSD variations.
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.
If you're not part of the solution, you're part of the precipitate.
Hooking up Ports to Slackware would have the merits that:
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!
If you're not part of the solution, you're part of the precipitate.
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.
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.
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.
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.
The line must be drawn here. This far. No further.
> 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.
25% Funny, 25% Insightful, 25% Informative, 25% Troll
But is it the very same ports tree for all 3 BSDs?
.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.
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
The line must be drawn here. This far. No further.
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.
The next comment I write will be ready soon, but subscribers can beat the rush and see it early!
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
In FreeBSD, this is the difference between a port and a package-- packages are what ports build. From the FreeBSD Ports page:
pkg_add will download and install dependencies, too.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?
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?
--
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.
-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. /stand/sysinstall has a binary package install utility built in.
-Fetch is broken (broken/truncated files) - See 1st question.
- Compile from sources only -
[Shrug] I don't see what your beef is.
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.
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
[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. 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).
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. :-)
(8-DCS)
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.
(8-DCS)
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.
.plan = NULL;
.sig =
Do the following really mean anything? SCSA MCP CCSA CCNA
--I'm not actually after an answer!
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.
Those who do not know the past are doomed to reimplement it, poorly.
Just to quote from the features section of openpackages.org:
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.
Well, the good news is, BSD is not dying. Whether that's due to it's cockroach nature or something else I'll leave for a seperate discussion.
What strikes me is that the entire discussion about Theo is done by anonymous cowards. Why is it that people do this? As the original AC stated so eloquently, Theo is a rather nasty character with excellent coding skills, the kind of guy I would hire on the spot and isolate as far as possible from any actual customers (or colleague coders for that matter). But I'd still hire him.
Then, why this fear of putting one's name on a posting? Theo has insulted me, but never tried done me any bodily harm (and on technical issues was right most of the time and taught me a lot).
[ I sometimes wish Slashdot had a setting to browse without the AC's, but of course that means that an extra moderated user category of whistleblower would be needed, and no, I wouldn't know how to get that to work... So much to do, so little time... Sorry, CmdrTaco :-) ]
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
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.
----------------------------
This is probably a mistake. Solaris is not BSD. SunOS 4.* is BSD. Solaris is SVR4.
Lottery: a tax on those bad at math.
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 . . .
tar.gz
====
Crudely Drawn Games
test
Only the State obtains its revenue by coercion. - Murray Rothbard
f00
Only the State obtains its revenue by coercion. - Murray Rothbard