Are you still using the old pkg_* packages?

Are you still using old-styled pkg_* packages?

  • Yes. I'm using the official pkg_* packages for 8.x

    Votes: 2 2.8%
  • Yes. I'm using the official pkg_* packages for 9.x

    Votes: 4 5.6%
  • Yes. but I'm creating my own pkg_* packages.

    Votes: 4 5.6%
  • No. I'm using the official pkgng packages for 8.x

    Votes: 2 2.8%
  • No. I'm using the official pkgng packages for 9.x

    Votes: 21 29.6%
  • No. I'm creating my own pkgng packages.

    Votes: 18 25.4%
  • No. I'm using the ports tree.

    Votes: 39 54.9%

  • Total voters
    71
  • Poll closed .

lme@

Administrator
Staff member
Administrator
Moderator
Developer
Please tell us what kind of packages you are using or if you don't use packages at all and still prefer building ports.

10.x and 11-CURRENT is of course out of this scope because PKGNG is default there.

EDIT: You can now select up to five answers.
 
I did not see the poll at the top of the screen. I would choose three (v9 tbz packages, own tbz packages, ports tree).

Just about a week ago I found I could install packages that seemingly wanted also the compiler (gcc47, for example, on a machine that did not have it installed) I did pkg_add -v -i -f and then the ones which were missing in the install message could be added if they were really needed for the port.

make -DNO_PACKAGE -DNO_STAGE -DMAKE_JOBS_UNSAFE reinstall sometimes results in two /var/db/pkg, one older, so one of the two is removed to fix that. I don't know how that would work with the new package system. And the directories (/var/db/pkg) while having erroneous errors, are maybe not as prone to being unusable even if they contain errors. I hope this answers something, and is not off-topic.
 
I think if we (VICOR) found that packages were no longer available for FreeBSD-8.4 or 9.3, we would first (a) panic and then (b) deploy binary packages from the previous release (running 8.3 packages on 8.4, running 9.2 packages on 9.3). While I expect that solution to work, I might add that FreeBSD 9.2 barely got binary legacy packages back and now we're talking about deprecating them? I have kindly asked that for posterity, we produce legacy packages for at the LEAST one more 8.x/9.x run. It is a far better thing to die happy and fulfilled than to die young (that is to say, it would be a travesty to continue to produce a minor revision but make a non-minor change such as deprecating the mainstream acquisition/format to the point that existing tools in the base system of those branches break!). POLA violation abound.
 
As far as I know the old packages will still be created for systems that use it by default (i.e. 8.x and 9.x). They won't be deprecated on existing, still supported, versions. Currently it's only 10.0 that has the new package system as default. Perhaps 9.3 may change to the new system but I think that's still being discussed. And there probably won't be an 8.5.

The only difference for existing 8.x and 9.x versions is that you can choose to go with the new system. You are not forced into it.
 
For my FreeBSD 9.2 servers I'm using the ports tree and using the current (old?) package manager to create the packages for further distribution. I have been playing with pkgng but don't feel confident enough yet to do the switch already.

In general I like working with pkgng; it's relatively easy to get around in if you're used to the current tools. Apart from some minor differences. For example; I had a little trouble finding the equivalent of pkg_info -W (identify the package which contains the file specified on the commandline) because I kept looking at the pkg-info(8) manual page. After that I tried pkg-query(8) while it turned out that I actually needed pkg-search(8), which I then confused for pkg-which(8) while originally writing this message ;)

However it does need a little work on the documentation and error messages. pkg.conf(5) includes an example configuration file which also uses the repos_dir option. Unfortunately that option isn't explained in the manual page itself yet. And because I only needed / wanted one directory I ended up defining a regular string, not an array. I assumed the array to be an optional setting if you needed to specify multiple entries.

That turned out to be wrong, but unfortunately pkg doesn't clearly tell you as much:

Code:
root@smtp2:/usr/local/etc # pkg info
pkg: Your pkg.conf file is in deprecated format you should convert it to the following format:
====== BEGIN pkg.conf ======
"pkg_dbdir": "/var/db/pkg"
"pkg_cachedir": "/var/cache/pkg"
"portsdir": "/usr/ports"
"handle_rc_cripts": false
"repos_dir": "/usr/local/etc/pkg/repos"
"syslog": true
"autodeps": true
"developer_mode": false
"pkg_env": {
    "http_proxy": "http://myproxy:3128"
}

====== END pkg.conf ======

pkg: Expecting a list for key repos_dir, ignoring...
This suggestion turns out to be incorrect since you don't need to put all options within quotes. It's merely that the repos_dir option is defined incorrectly. The moment I change this into the right format everything works normally again:

Code:
repos_dir: [ "/usr/local/etc/pkg/repos" ]
Although pkg does correctly note that it expected a list for this option I was a little confused at first about the comment regarding the use of an deprecated format. It even suggested using the wrong option.

But apart from those small oddities it works pretty smoothly in general. I also like the way the package system now combines external features such as package auditing as well. It really makes sense to have those features rolled into one program.

Edit: Added pkg-which reference to avoid possible confusion.
 
ShelLuser said:
In general I like working with pkgng; it's relatively easy to get around in if you're used to the current tools. Apart from some minor differences. For example; I had a little trouble finding the equivalent of pkg_info -W (identify the package which contains the file specified on the commandline) because I kept looking at the pkg-info(8) manual page. After that I tried pkg-query(8) while it turned out that I actually needed pkg-search(8).
pkg-which(8) ;)

pkg which /usr/local/sbin/pkg
 
I exclusively use the ports tree to install/upgrade ports with portmaster, switched to pkgng for ports information, i. e. pkg info, pkg version, pkg updating, etc. instead of old versions, they run faster.

I switched to the new pkg system about eight months ago in a FreeBSD 9.x installation running in VM and about four months ago in a real machine with a fresh FreeBSD 9.2 installation, it always worked the same way as the old package system. So, I don't install/upgrade ports using packages but like the new pkg system.
 
A thought: if 9.3+ is to switch to PKGNG and not generate legacy packages, I will have to MFC bsdconfig patches from 10.0 to start using PKGNG.
 
Well, 9.3 is still a long way away I think. Personally, I wouldn't mind if 9.x kept the old packages as standard and using the new system from 10.0 onwards.
 
fonz said:
lme@ said:
EDIT: You can now select up to five answers.
But you can't add anything if you had already voted before.

Please try again, it should work now.
 
I use the new pkgng and love it. It beats the hell out of the ports tree for installing, upgrading and auditing. It isn't hard to get used to at all either. Good job FreeBSD. Not quite as good as most Linux package management systems but at[ ]least you're now catching up to the 21st century.
 
Virtual packages with virtual dependencies. The ability to install for example different versions of Perl side by side without them conflicting with each other. A stable ports tree with feature lock for a promised support period. Some of these are of course not something that can be solved with PKGNG alone.
 
I hear something called a "PBI" can solve the problem of virtual dependencies and having different versions of Perl side-by-side without conflicts. However, I don't know if PBI's can be used with FreeBSD -- whereas I know they are in-use for PC-BSD. As for feature-locking the ports tree... how would you imagine that working? How does something like emerge support this? BTW, did you know that it's possible to pull down tagged ports (just as a side-note, it is possible to use the ports tree in a traditional SVN fashion as there are indeed tags for the releases and sundry events).
 
PBIs are the PC-BSD fat package format. Hmm, the PC-BSD web page has become a FreeNAS web page, so no link for now. There are FreeBSD ports for dealing with PBIs.
 
I voted ports, but on my newest server which is on 9.2 I have just upgraded to PKGNG as the enhanced tools are still useful for those of us using ports. I wonder whether on systems with PKGNG installed aliases should be set up so e.g. pkg_info is aliased to pkg info as it will take me some getting used to with the new commands.

I hope there is are no plans to ditch the ports system though as it's FreeBSD's main strength, I am not a fan of precompiled installations.
 
I voted for the official PKGng packages for FreeBSD 9.x. I am very happy with the new package management system. If I eventually get a more powerful box I will compile applications with ports.
 
chrcol said:
I hope there is are no plans to ditch the ports system though as it's FreeBSD's main strength, I am not a fan of precompiled installations.

Considering that packages, both old and new, are built from ports... no, ports are not going away.
 
Back
Top