please explain to me something that I cannot find in the handbook

J

jrl1357

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?
 
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.
 
jrl1357 said:
7. (as above) How to I update my packages?
Click to expand...
Update packagename-x.y-z (You can ignore version number)
# portupgrade packagename

Upgrade 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 packagename

Rebuild and reinstall all that ports that were installed prior to the date 2011-12-13:
# portupgrade -f '<2011-12-13'

Reference: portupgrade(1)
 
jrl1357 said:
1. Is there any real advanage to using ports over packages if I don't plan on making any changes?
Click to expand...
Not all ports have packages, like audio/lame or editors/libreoffice for example.

3. The command to install a package is pkg_add -r [package] correct?
Click to expand...
Yup, also try pkg_add -rv package for more verbose output.

4. FreeBSD will fetch dependices right?
Click to expand...
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?
Click to expand...
Packages are built ports, so the effect is the same, add a package or compile a port with default options.

6. Is there a package for every port (and vesaversa)
Click to expand...
Not all ports have packages, but to build a package You need a port, so all packages have port.

7. (as above) How to I update my packages?
Click to expand...
By binary way: http://forums.freebsd.org/showthread.php?t=26140
Or by recompiling with portmaster -a.

8. Does the package of a DE (such as Gnome) also have all the basic tools of said DE? (ex. leafpad, xterm etc.)
Click to expand...
Depends on the metaport.

9. When I pkg_add(1) something, do I need the version as I do in pkg_delete(1)?
Click to expand...
You do not need to version for pkg_add(1), You need version for pkg_delete(1) or You can use -x flag of pkg_delete(1), so you would not have to pass exact version to it.

10. What packages are need to run the de that arnt included? (such as x)
Click to expand...
Just add x11/xorg port and you are done.

11. Can I list multiple packages in a pkg_add(1)? (pkg_add gnome xorg)
Click to expand...
Yup.

12. Is the FreeBSD forum welcoming of newbs?
Click to expand...
Sure, welcome ;)
 
hadrons123 said:
Why can't FreeBSD build binary packages and place it in a repo, as soon as the ports updated everyday?
Click to expand...

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.
 
phoenix said:
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.
Click to expand...

No way to continue using /var/db/pkg?? What would be its near-equivalent? I've several times yearly where it is indispensable, for instance, finding which dependency has least-recently been installed, grepping out all py26 for a python2.7 upgrade, using tab-completion to check if a port is already installed in one xterm while constructing a long list of ports to feed to portmaster in another xterm, finding out how many *diff* ports are actually installed, etc etc...
..... 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 +CONTENTS to find dependencies, /bin files
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.
 
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.
 
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 pcre

Code: 
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
 
Beastie said:
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.
Click to expand...
I've read this reply, then the pkg manpage. I see no way to tab-complete a list of ports to feed to portmaster, one by one, when I know their names onscreen from a file... for instance. I could maybe
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?
...
 
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.
 
Beastie said:
jb_fvwm2, why would you still want to use the pkg_* commands when pkgng is ready and integrated as default package manager?

Watch this video and you'll understand it's much better. Check at 0:11:21 for all the available commands.
Click to expand...

I see that it is an excellent front end to to ports tree and package management. However, I also know that portmaster and the shell's tab-completion (and script) are an excellent front end to the ports tree and package management. (I've a third set of .zsh I use sometimes instead of portmaster which I wrote before it appeared).
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...
 
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.
 
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...
 
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.
 
[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...
 
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
Not too promising...
 
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!
 
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...
 
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...
 
You must log in or register to reply here.
Back
Top