You not only have to keep the name of the package, it's flavors, it's description, it's checksums, but also it's BSD makefile and it's patches. You could put that all in one file, and it would be oooooh, say 161MB. i.e. WTF do you think those files are in the tree? The source get's downloaded when you need it. The only thing in the tree is meta-data, which you have to have, so yet again you're WHINING ABOUT LESS THAN 200 MB.

This is not 1990. Stop making up excuses to whine. You don't have any point, what so ever. Full stop.

0 members found this post helpful.

In general, the OpenBSD project recommends installing packages over building ports, however, all ports have not been pre-compiled into packages on all platforms. It is not clear from the information I find in your posts which indicates that you need to either install the ports tree or locally build ports. More information can be found in Section 15 of the FAQ, & you will save yourself significant aggravation by taking the time now to study it:

http://openbsd.org/faq/faq15.html

But the data is broken up into different files so the developers can laugh when someone complains they have to make search key=some_package and then cd to that dir! Screw maintainability, it's more important to make it cd-less. Don't you follow along in the ports mailing list? =D

You clearly don't understand my proposition - which was not even that important anyway - but here is a second attempt:

"The only thing in the tree is meta data, which you have to have", but why do you have to have meta data of countless applications that you will never ever install in your entire life? I have the ports tree here, I've been looking at it and I don't think I would ever install any more than 5% of it. So what's the point of keeping meta data of the remaining 95%?

rocket357 mentioned OpenOffice. I do think that OpenOffice is too big. But I have no alternative and - that's important - I actually use OpenOffice, unlike that 95% of ported apps that I will never use but have to keep their 160Mb of meta data even if I never get to use it. Everyone here seems to think that 160Mb is peanuts, but I think it's an awful lot for something I will never use - unless I need one or two ported apps, then I have to have meta data of the whole lot. It's wasteful. It's dumb!

Again: my suggestion is to keep the ports tree remotely, at ftp.xxxbsd.org and the mirrors. And a catalog or "map" of that tree locally with information like:

audacity
Good sound editing program
ftp.xxxbsd.org/ports/audio/audacity.tgz
Depends:
sound-libz-0.4.3
oggnogg-1.5.2

Then, if you run...

# portinstall audacity

... this hypothetical portinstall command will look up 'audacity' in the local catalog and just know that it can be obtained from ftp.xxxbsd.org/ports/audio/audacity.tgz. Then it downloads the meta-data and the source and dependencies (if any) and installs it in exactly the same way it already does now. rocket357 mentioned maintainability. It's still a tree, the same old tree, except each application's directory will be tarballed so it can be downloaded individually. That's all. Nothing changes in terms of maintainability.



News flash: "Full stop" are not magical words. You can't resolve an issue with them. You can, of course, retire from the discussion with them, but you don't need them for that.

You should stop referring to my ideas as "whining". Instead, you could explain why it's OK to have pkg_add -r download applications and dependencies from a remote location on demand, but it's not OK for the ports system to do the same thing. I think I do have a point, that's why I am so stubborn about it. I am willing to change my mind if you offer some logic and sensible argumentation instead of insults.

Ultimately, it doesn't matter. Nothing is going to change because of my ideas and a silly forum debate. I don't entertain such expectations. I started this debate because I want to learn and I am interested in what people have to say about the issues I raised that really astonish me. That's what I think forums are for. That's all. If you can enlighten me with your experience and feel like sharing it today, that's great. But if I annoy you, then you had better just walk away from this debate and be happy with your mind set on something else. My ultimate goal here is explore what I perceive as issues, their possible solutions and points of view. My goal here never was to make people angry. If you think I am "whining", then I suspect you shouldn't take part in this conversation in the first place.

So you want to have a tarball of each of the Makefiles/metadata for each port, such that each port's metadata can be downloaded on demand during a given port's installation.

Sounds great! How long do you think it'll take for you to code it? (not being malicious, I'm genuinely curious). I could see having a server that syncs the ports tree once every 24 hours or so, but then you run into an issue of STABLE vs. CURRENT, etc... so it could be split off into different directories, and each RELEASE/STABLE/CURRENT directory would contain each respective tree. (I could see this being useful for embedded systems, though typically you'd build the port on a different machine and transfer it to an embedded system).

The biggest issue I see is modifying the Makefile to look remotely instead of locally for the metadata for dependency ports...that's a bunch of Makefiles to go through!

And to answer why it's not done this way, I'll again pick on FreeBSD =P (since Gentoo and OpenBSD ports are both based on FreeBSD's ports system). I guess "why isn't it done this way" would be a question for the FreeBSD team...and I suspect the answer lies more in "it started off small, so we didn't think it'd matter?" but now it's 385 MB on FreeBSD, 328 MB on Gentoo, and 192 MB for OpenBSD-CURRENT.

Herein lies the beauty of Open Source. If you can think of a better way to do things, you're more than welcome to implement it.

Edit - Just for the record, you can mount /usr/ports via network share and set WRKOBJDIR in /etc/mk.conf to make /usr/ports read-only (and so you only have to maintain one /usr/ports tree on your network (as long as all the OpenBSD machines are running CURRENT, or STABLE, or whatever the ports tree is synced to)).

Edit #2 - Actually, if you were to implement a ports system like this, the mirrors could keep track of what ports are used most often, which would be nice for prioritizing fixes and what-not.

Edit #3 (last one, I promise =) - Doh! I didn't read your post very closely...you mentioned maintaining a small db of metadata about the metadata (i.e. where to find the port's metadata). It wouldn't require modifying Makefiles if done that way...my bad.

Edit #4 (ok, ok...I lied) - The ports tree's purpose is to allow for specialty builds (flavors, in OpenBSD terms) of packages. Want package X without Samba support? Well, if the package was compiled with Samba support, then pkg_add will pull in Samba. The way around that is to install from ports. As per the FAQ, though, you should always use packages over ports =)

1 members found this post helpful.

The data in the ports system can be compared to the Gentoo portage tree - a _lot_ of very small files.
If you put these onto a filesystem created for normal use - or even large files - a lot of space will be wasted.
If you dont want or like that, you can work around it.
- tar and compress the ports tree - and only uncompress when needed
- put it on its own partition - which has a filesystem more suited for a lot of small files (that is what I did in Gentoo)
- look into other approaches to this - similar things could be done in BSD too:
http://www.gentoo-wiki.com/HOWTO_VER...FS_and_UnionFS
http://www.mhampicke.de/wiki/index.p...ee_verkleinern

It's like keeping a cow at home if cows were the size of cats, perhaps. The ports tree just isn't very big, particularly next to the binaries for OpenOffice and FireFox etc.

lucmove, I don't really understand you at all.

When you decide to use PC-BSD :
- you should know that you can compile but there are probably ready to install packages. If there are no packages, you should look if a guy from PC-BSD team has a website with some extra binaries.
- you should know if PC-BSD use the ports tree database or have a custom database.
- etc.
- in general you should know what's the difference between a "pure BSD" and the "bastard version" you're using (is there a preferred way to do something, is everything the working the same?)

There are probably many things you are not aware of in general that you should be.

I'm a long-time Slackware user and I'm frankly a bit embarrassed by this thread. As a Slackware user I pride myself on being able to fix it myself and I do read the manual. I also am a novice FreeBSD user. But, I don't whine about how difficult FreeBSD is to use or complain about perceived system flaws. Some advice for you, lucmove. You need to more fully learn about BSD and get your hands dirty. Crap, you're giving Slackers a bad name.

0 members found this post helpful.

- This thread isn't about fixing anything.

- Being able to fix things is good, but I'd rather pride myself on other things.

- No one is going to think ill of Slackware because of one guy.

Without BSD Slackware could not be what is is now, or any other distro for that matter. Windows and Mac have used things from BSD. Name a distro that is not using something that came from BSD. Many distros are based on Debian for good reason.

At Wed Sep 24 01:25:28 CDT 2008 http://distrowatch.com/ listed the top ten distros as

1st Ubuntu based on Debian
4th Mint based on Debian
6th Debian is Debian
8th Dreamlinux based on Debian
9th Damn Small based on Debian

3rd Fedora based on RedHat
5th PCLinuxOS based on RedHat
7th Mandriva based on RedHat

2nd openSUSE based on Slackware

10th Sabayon based on Gentoo

This says a lot about Debian. If this is correct 5 out of 10 top distro are based on Debian.

0 members found this post helpful.

And Britney Spears ranked first in Google's top searches for years. What do you expect to prove with that figure parade? 50 million Elvis fans can't be wrong?

If you want to build things, you have to put up with some lost space. I don't really want /usr/include on my home computer, but I can't do without it. On the other hand, instruments I've put out in the field just can't waste that precious Flash RAM so I've spent months making sure that the development scripts strip out absolutely every unnecessary file. For ports I guess it's a simpler task to update the whole bunch of files rather than go through the hassles of sorting out version dependencies when someone makes a change to an application. Just look at the space "wasted" by your favorite Linux package manager's software list. How about the numerous system tools installed which you don't use and no script on the system uses. How about WinDuhs - now there's a waste of space.

You've also got to be careful pulling in software from multiple sources; inexperienced Debian users often do that and horrible things happen to them because dependencies are all wrong. That's just a matter of understanding the package management system and knowing what to look for.

I can't criticize the encrypted filesystem because I haven't looked into the details of any. Just because you discovered something you think is horribly wrong with a particular implementation doesn't mean that other implementations you've used don't have similar or worse risks.

Then of course no system is perfect - you might have to wait years for some feature you want to appear. Don't forget the *BSD community doesn't enjoy as much support as Linux so development (including addition of drivers) is not as rapid. Despite that, *BSD developers have come up with quite a bit of code which had since been used in Linux (like the earlier Atheros chipset driver).

*BSD is just another tool - if it works well for a particular job, use it - if you're more comfortable with using something else to do the same job then use that. There's a whole world of WinDuhs users out there and not many people are in any hurry to try to get them to use anything else.

My point was not just about fixing things. The main point I was making is that Slackers are for the most part individualists who stand on their own two feet. Stop whining about BSD. Either learn about it or stop using it. Grow up. Do you really think that the BSD community cares that a rank beginner dislikes how BSD functions?
I enjoy the challenge of learning FreeBSD. I'm not completely comfortable with it, but, therein lies the joy of things. FreeBSD is a rock-solid OS.

0 members found this post helpful.

Britney Spears and Elvis are just like Slackware fans. They have loud unintelligent fans and do not influence new music. Slackware is the Britney Spears of linux, nice on the outside but clueless and non-functional. Encrypted /home BS if, I get your computer I have all the time I need to decrypt your disk using your keys. Stupid blond Slackware/Britney fans. I wonder if Britney runs slack looks like a nice fit.

0 members found this post helpful.