236e4
![]() |
|
|
|
|
|||||||
| Installation and Maintenance of FreeBSD Ports or Packages Installing and maintaining the FreeBSD Ports Collection or FreeBSD Packages (i.e. third party software). |
![]() |
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
|
Ok, so after trying PC-BSD out in a VM and desiding PBIs suck (IMO). I'm installing FreeBSD in a VM. Anyway, I don't quite get the package/ports thing. What the handbook does not have, is how to update packages. Ports, yes, but not packages. Now, I have a couple other questions I was hoping someone would anwser to clearifi things I've read in the handbook.
1. Is there any real advanage to using ports over packages if I don't plan on making any changes? 2. On a system using an amd phenom ii x4, about how long would a big package such as gnome take to complie from port? 3. The command to install a package is pkg_add -r [package] correct? 4. FreeBSD will fetch dependices right? 5. The handbook seems to talk about the ports tree is if it is actully on your system. What does this mean? Is it the same for packages? 6. Is there a package for every port (and vesaversa) 7. (as above) How to I update my packages? 8. Does the package of a DE (such as Gnome) also have all the basic tools of said DE? (ex. leafpad, xterm etc.) 9. When I pkg_add(1) something, do I need the version as I do in pkg_delete(1)? 10. What packages are need to run the de that arnt included? (such as x) 11. Can I list multiple packages in a pkg_add(1)? (pkg_add gnome xorg) 12. Is the FreeBSD forum welcoming of newbs? Last edited by SirDice; August 3rd, 2012 at 08:00. Reason: Proper capitalization: http://en.wikipedia.org/wiki/Capitalization |
|
#2
|
||||
|
||||
|
A dozen questions... I'll answer some and leave others for someone else.
Before starting, it's worth noting that a rewrite of the package system known as "pkgng" is due to come out Real Soon Now. It solves many of the common problems with the current package system. 1. Some ports can be built to take advantage of CPU features. Whether that matters depends on which ports you use. 2. Too many variables. Depends on RAM, disk speed, how many dependencies are already installed, and so on. Big applications take a long time. 3. Not exactly, -r downloads a package from one of the package servers. Otherwise, the package name is just a local file. 4. Yes, generally. 5. If you want to use ports, the ports tree (/usr/ports) must be on your system. Packages are merely the built (binary) version of ports. After a port has been built, the ports tree is no longer required. 6. No, not all ports are built into packages. There are various reasons including license and size/time to build. 12. Generally, yes. As a group, we particularly like it when posters take care to use proper English, including capitalization and punctuation. |
|
#3
|
|||
|
|||
|
Why can't FreeBSD build binary packages and place it in a repo, as soon as the ports updated everyday?
|
|
#4
|
|||
|
|||
|
Update packagename-x.y-z (You can ignore version number)
# portupgrade packagenameUpgrade all the packagename packages just by package not ports (you need port tree anyway) # portupgrade -PP ’*packagename*’Upgrade packagename and all that packagename depends on, and building binary packages for the upgraded packages: # portupgrade -Rp packagenameRebuild and reinstall all that ports that were installed prior to the date 2011-12-13: # portupgrade -f '<2011-12-13'Reference: portupgrade(1)
__________________
Zhoopin (ʒuːpiːn) - Meri - Mehrshad Moslehi |
|
#5
|
|||||||||||
|
|||||||||||
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Or by recompiling with portmaster -a. Quote:
Quote:
Quote:
Quote:
Quote:
__________________
Religions, worst damnation of mankind. "FreeBSD has always been the operating system that GNU/Linux should have been." Frank Pohlmann, IBM http://vermaden.blogspot.com |
|
#6
|
||||
|
||||
|
It's in the works. Google (or search these forums, even) for pkgng. The tentative plan is to make it optional in FreeBSD 10.x, and mandatory in 11.x, with ports available for 8.x/9.x.
|
|
#7
|
|||
|
|||
|
Quote:
..... a few more... Portmaster build fails, create a pkg manually using tab-completion so one does not have to write down its numeric part. Completing portmaster cli lists with no having to write the number or the latter part of the name. Code:
pkg_delete -f port-number && pkg_add /mnt/portmaster-download/port-number.tbz # Ive a machine with no space for pkg left, and the above command only works from /var/db/pkg, the shell cannot tab-complete from elsewhere for some reason Checking +REQUIRED_BY before attempting an upgrade # indispensable IMHO Storing the above file in the port itself for faster access Finishing corrupt installs (i.e, a pkg fails to register, with pkgng, almost impossible with the present system. Other stuff I've not thought of. Apologies for easy equivalents I coould know with a few hours of reading. However I am not optimistic that the documentation nor implementation will be complete enough so that it *should* be mandatory... maybe just a vote for delaying it a few releases, I don't know. |
|
#8
|
|||
|
|||
|
jb_fvwm2, why would you still want to use the pkg_* commands when pkgng is ready and integrated as default package manager?
It will fix all that is wrong with the pkg_* commands. From what I remember it'll be a single tool that will do the job of all the pkg_* commands, plus many port/package management scripts currently only available in the port system (e.g. sysutils/bsdadminscripts). It will be extensible and more secure. Package information will be stored in a database instead of thousands of tiny files and you'll be able to do backups of the database itself or backups of all the individual files that make up the database. Watch this video and you'll understand it's much better. Check at 0:11:21 for all the available commands.
__________________
May the source be with you! |
|
#9
|
|||
|
|||
|
Everything you mentioned will be available trough the pkg(8) command and much faster and in more robust way. Let's say you want to find out which packages depend on devel/pcre:
$ pkg info -r pcreCode:
pcre-8.31 is required by: lighttpd-1.4.31_4 graphviz-2.28.0_1 nmap-6.01 R-2.15.1 gobject-introspection-0.10.8_2 gamin-0.1.10_4 gio-fam-backend-2.28.8_1 pango-1.28.4_1 cairo-1.10.2_4,2 rrdtool-1.4.7_2 ntop-4.1.0_5 glib-2.28.8_4 dbus-glib-0.94 xmms2-0.8_1 avahi-app-0.6.29_3 samba36-3.6.7 php5-5.4.5 php5-session-5.4.5 php5-posix-5.4.5 nss_mdns-0.10_2 wireshark-1.8.2 py27-xmms2-0.8_5 |
|
#10
|
|||
|
|||
|
Quote:
write sqlite3 wrappers to handle stuff like that? ... Thanks (below) for the completion options suggestion. (checking the manpages, though, they are way beyond my expertise...someone may put their methodology in the wiki?) Bookmarked... Howsoever, what of machines (router on a stick, CF based atom machines, p2 laptops... ) that for some reason could handle the present way of upgrading (portmaser less than porupgrade...) but not something more heavyweight like sqlite3? ... Last edited by jb_fvwm2; August 22nd, 2012 at 21:24. Reason: routers... |
|
#11
|
|||
|
|||
|
Look into the completion options of the shell you're using. What you need is completion based on a list of packages from pkg(8). The completions that are included in ports-mgmt/portmaster (if you select the options) may be a good starting point.
|
|
#12
|
|||
|
|||
|
Quote:
Howsoever, I see no compelling reason to have the pkgng system as *mandatory* in any future release[1]... would not a choice of two extensible methodologies serve as better for freebsd in the long run than deprecating something that "just works" mostly? [1] that discussion continues on the freebsd-ports mailing list this month... |
|
#13
|
||||
|
||||
|
pkgng is not a replacement for portmaster or portupgrade, or a replacement for ports. It's a replacement for the old package tools: pkg_add, pkg_info, pkg_delete, and so on. pkgng fixes a lot of the problems and adds new capabilities.
|
|
#14
|
|||
|
|||
|
So if it is mandatory, will /var/db/pkg still exist? Maybe I am confused.
With /var/db/pkg, each port is "in plain sight" as it were. One can without knowledge of pkg_add etc use the port tools and front ends (BTW portmaster contains at least 37 usages of pkg_*... My abilities to handle upgrades seamlessly would be impacted AFAIK if it were deprecated. Further, pkg needs 19 .so. files, where the legacy ones used 3 or 6 each. If a bug is introduced in sqlite3 or pkg that makes their use suddenly impossible, would the legacy stuff be around for recourse? (please see below about an timely but unfortunate thread elsewhere...) Just now reading the pkgng wiki, it seems whereas all the metadata will be stored in the pkg database, as of *now* EACH /var/db/pkg/name-number serves as its OWN pkg database (in a manner of speaking.). So someone may chime in that /var/db/pkg will/may continue to exist or not... or if it is indeed deprecated maybe I could write a front-end to pkg to recreate it locally. ... None of the threads I've found hint that /var/db/pkg can coexist with a mandatory pkg(ng); and the CLI examples that show equivalents to what may take a *few seconds* of tab completion (here), seem to be full lines of quoted variables and such, so would need an alias at least to implement. ... ( sentence deleted. Please see maybe more elucidative paragraphs in postings to the freebsd-ports list this month.) ... BTW after saving this thread (again) for recourse should pkgng become mandatory, I ran across in the .htm's destination directory, a freebsd-questions-digest post (from this month) detailing pkgng hosing a server upon unsuccessful reinstall or upgrade of apache... Last edited by jb_fvwm2; August 24th, 2012 at 02:05. Reason: Reluctance to stray from main reason for the post. |
|
#15
|
||||
|
||||
|
There are patches for portmaster and portupgrade to use pkgng tools. As to backwards compatibility, AFAIK there isn't any. The text files in /var/db/pkg can--and do--become corrupted sometimes, and it breaks things until they are fixed. Given the attention to detail shown by the group working on pkgng, I suspect it will be no less reliable than the old system.
So... don't panic. Set up a VM and try pkgng out. Report problems, the team is very responsive. |
|
#16
|
|||
|
|||
|
[reply erased ]
Suppose an analogy... A manpage management tool... for a manpage to be installed, it is metadated into a tar file... and a manpage installer/deinstaller handles the addition/subtraction/viewing of man pages. Seems like a new point of breakage...IF it was mandated that the original system is deprecated and will no longer be existing, VS if they coexisted. I suspect the authors of pkg may have not thought entirely through the ramifications of deprecating /var/db/pkg rather than further developing pkg so as to coexist with it... [1] *Seems* like a /etc/.conf >> windows-registry abstraction layer, and whereas before I'd happily recc. FreeBSD, it becomes a bit more "irrevocably automated" as it were, and persons might have viable reasons to use windows or linux instead... even if ever-so-slightly, the fine-grained grep/find etc management of /var/db/pkg one can craft (as in the case of portmaster itself...) becomes irrelevant. So while the new package system may be reliable (per my posts above, any less reliability than now is totally not needed...), IMHO Freebsd becomes a bit less capable, all told (one talking point removed if one is discussing at length the non-merits of a registry vs .conf and .rc files, for example. ) [1] Why not a kernel option to deprecate /var/db/pkg if that is one's wish ?? or something equivalent. Sorry for any misconceptions I may still have, causing the opinions above to be unfounded... |
|
#17
|
|||
|
|||
|
I was wondering if a p2 - 266mhz could comfortably run pkg.
Code:
(machine... pentium 4 2.0 ) pkg stats Unable to open remote database "repo". Try running 'pkg update' first. pkg update Updating repository catalogue zsh: segmentation fault pkg update |
|
#18
|
|||
|
|||
|
Start by reading the ressources, we don't have much, and we hope people will help us improving it, but
- https://github.com/pkgng/pkgng/blob/master/README.md - https://github.com/pkgng/pkgng/blob/master/FAQ.md - http://wiki.freebsd.org/pkgng (on this page you can find links, articles, videos about pkgng) - http://wiki.freebsd.org/PkgPrimer Concerning the segfault it is a small bug that has been fixed in git (it is because you have configured at all your pkgng) |
|
#19
|
|||
|
|||
|
jb_fvwm2, why so much pessimism? Do you realize pkgng won't be adopted as a default package management system before... maybe two years from now?
"segmentation fault" means there's a bug somewhere. And there could be hundreds of them right now. It's under heavy development/testing. As for the "/var/db/pkg thing", there will be a SQL database instead. And as I already said (and as is mentioned in the video above), pkgng will provide a way to make backups. The pkg_* programs have been there for ages and it was about time for a replacement. Things change -- for the better, hopefully!
__________________
May the source be with you! |
|
#20
|
|||
|
|||
|
Pessimism... please see the post I made earlier today to the freebsd-ports list, in
which I detail that a SQL database instead, is forking FreeBSD to be more windows-like, (a registry instead of .conf , .rc...) Two years, too soon... I cannot enumerate the numerous times yearly I use low-level tools (sed, find, grep, awk) and /var/db/pkg flat-files, pipes, sh one-liners, etc, to fix mismatches between what I wish the /var/db/pkg to be at within a few *minutes* and where it is now... The memory expense, programming expense, manual-reading expense, not-so-immediately-obvious results... I do not wish to disparage pkg(ng) development, howsoever I've no doubt that its being the default, with no choice to continue as-is, [1] is a disservice not only to a subset of the FreeBSD community, but to potential users of FreeBSD, the pc-bsd community and its potential users, the ghostbsd community and its potential users, the pfsense community and its potential users, persons running on lower-power or legacy gear that would be more severely impacted by heavier-weight package tools... (I've a p2 that cannot build ruby18 at least without difficulty... ) ... And we "deprecate"... suppose someone crafts something a magnitute better than portmaster and/or portupgrade? That appears discouraged without SQL programming... [1] Why not do a bit more programming and make that a non-default kernel option? The deprecation of /var/db/pkg that is... |
|
#21
|
|||
|
|||
|
Unproven or undocumented fixups with pkg??
pkgdb -F Stale dependency fixups and dependency updating Resintall of all ports per the procedure in the portmaster manpage A check on the /var/db/pkg subdirectory should a "make install" fail A check on the /var/db/pkg subdirectory should a "make deinstall" fail Tolerance of ports installed with conflicts (one can uncomment the line in a Makefile and install both... vs other more recommended ways that would take a lot more time.) (vs a "refusal to register" error message with pkg... |
![]() |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| [Solved] Could someone please explain this to me? | Anon | General | 3 | March 5th, 2012 02:59 |
| [Solved] Can anyone explain clamav to me? | rajl | Installation and Maintenance of FreeBSD Ports or Packages | 5 | February 15th, 2012 18:18 |
| Please explain Giant-locked | pippo | Installing & Upgrading | 4 | May 4th, 2010 20:56 |
| can someone explain :) | Myron | Networking | 18 | December 19th, 2009 09:59 |
| [Solved] Handbook for 8.0 RC | enclair | General | 8 | November 11th, 2009 20:41 |