Are you still using the old pkg_* packages?

[kpa]

Pkg did not care about my ports built with custom options, and wanted to reinstall/overwrite them with default packages from repository. Had to comment out the relevant lines in the source of pkg.

This has been explained over and over again. The official packages are built with default options and default dependencies. There's absolutely no way to change the options or the dependencies at install time, they are effectively "set in stone" at compilation time. This behaviour is directly inherited from the old pkg_* packages that didn't have any more capabilities in this matter than the new pkg packages. There is ongoing work to remedy this shortcoming but the results of this work won't be in use until ports-mgmt/pkg version 1.3 gets released.

 

[Juanitou]

IMHO, you should better use pkg lock.

 

[kpa]

Or better yet, don't mix the official packages with anything you build yourself. Doing so will result in trouble as witnessed countless times.

 

[sk8harddiefast]

I use ports for installation and updating. I use pkg to delete ports. Sometimes I install packages using pkg when I see that there are no flags for the specific port and I want to avoid huge compiles.

Gene

 

[NewGuy]

What is missing in your honest opinion to make pkgng equal or better than apt/yum/emerge?

I like PKGNG, it is a step forward in my opinion. Still, there are some minor issues. Usually these issues seem to arise due to poor dependency settings in the port itself. For example, if I install the Dovecot2 port and then install Postfix (two packages that work together) the pkg package manager will remove Dovecot2 and install Dovecot1. This is a problem since I can't get Dovecot1 working with the current version of Postfix, however Dovecot2 does work with the current version of Postfix.

In another instance I found if I installed MariaDB and then installed something AMP related, MariaDB would be removed and replaced with MySQL. This is silly since MariaDB and MySQL are virtually the same software, but the former is getting more community maintenance.

In short, the dependencies are sometimes wrong and there doesn't appear to be any easy way to override them with pkg and keep the proper packages installed. Even if a package is locked, it can still be removed and replaced with a different (unwanted) package. So, for these items at least, I ended up using ports.

 

[kpa]

I like pkg-ng, it is a step forward in my opinion. Still, there are some minor issues. Usually these issues seem to arise due to poor dependency settings in the port itself. For example, if I install the Dovecot2 port and then install Postfix (two packages that work together) the pkg package manager will remove Dovecot2 and install Dovecot1. This is a problem since I can't get Dovecot1 working with the current version of Postfix, however Dovecot2 does work with the current version of Postfix.

in another instance I found if I installed Mariadb and then installed something AMP related, Mariadb would be removed and replaced with MySQL. This is silly since Mariadb and MySQL are virtually the same software, but the former is getting more community maintanence.

In short, the dependencies are sometimes wrong and there doesn't appear to be any easy way to override them with pkg and keep the proper packages installed. Even if a package is locked, it can still be removed and replaced with a different (unwanted) package. So, for these items at least, I ended up using ports.

The dependency problems really stem from the fact that PKGNG does not implement anything new in that department compared to the old packaging tools. All dependencies are concrete and can not be really changed after package creation (with exceptions as documented in /usr/ports/UPDATING for certain cases).

 

[jb_fvwm2]

I'm expecting pkg upgrade to specifically state which of the updates require a deinstall, maybe the listing split into six parts rather than the three-part one seen here, eventually. Similarly with pkg install. For example, lang/ruby19 should be deinstalled before new packages requiring lang/ruby20.

 

[silicium]

I can't let pkg deinstall or reinstall anything that was not requested on the command line, just because a few dependencies are unable to know if they match packages that were installed from ports. In the source of pkg, where is the code that checks for dependencies, and create a list of (not really conflicting) packages to remove or upgrade ? I will make these actions optional.

 

[l2f]

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 use the new pkg with 10.1 but I prefer the old pkg, I missed some commands arguments from the old version:

• pkg_create -n -R -b packagename

  to create pkg with dependencies.

• pkg_info -L /var/db/pkg/packagename

  to get the files belonging to this package, now I have to do find the package name

  pkg search packagename | more

  and after I have to write:

  pkg info --list-files packagename

• etc.

Why rely on sqlite to store the information? The Unix spirit is to use ascii format, easy to read and to edit (vi), it looks like the Microsoft registry...

I prefer to use the port tree.

 

[wblock@]

pkg_info -L /var/db/pkg/packagename

Use a shell completion and it is even better.

Why rely on sqlite to store the information?

Because it is less likely to have corruption than the text-based files were and much, much faster. Users of older versions remember waiting on "registering package..." messages.

I prefer to use the port tree.

But the ports tree uses pkg.

 

[TheDreamer]

Why rely on sqlite to store the information? The Unix spirit is to use ascii format, easy to read and to edit (vi), it looks like the Microsoft registry...

Because it is less likely to have corruption than the text-based files were and much, much faster. Users of older versions remember waiting on "registering package..." messages.

Speaking of the sqlite database, is there anything to deal with corruption or other issues? When I converted one machine to pkg, feels like something went wrong, because pkg operations are much slower than they were pkg_* operations.

I recall that I tried an 'optimize' (dump and reload), but pkg refused to reconigize the result, so restored the original db. Figure something different about how its sqlite works compared to my build of databases/sqlite3?

For a long time I was stumped by messages during the day that were like "waiting for lock", or failing because its locked. I'm the only user on the machine....though sometimes because its so slow I might have accidentally tried the command again in another window...but eventually found that it was the daily pkg audit or checksum that was taking most of the day to run, instead ~10 minutes on this machine (which has 2119 packages while the slow one has 1543 packages) was the likely culprit.

I would expect that my machine having SSD root pool vs the slow machine have just a pair of spinning disks....except maybe for them being write optimizing drives....wasn't the reason for the huge differences.

For some reason I had hoped that there's something special in my a basic dump and reload wasn't ok, and that pkg backup and restore would do....but all it seems to do is make a compressed copy in /var/backup and then decompress it back for restore. I have also been hoping with each new release that it might take care of the problem...but so far it persists.

Also interesting is that my sqlite database is 92M, while a .dump of it is 67M. Though create an sqlite database from the dump results in a 95M file. OTOH if I do a vacuum of the original database, the result is 88M, while vacuum of database from .dump file is 87M....

pkg will work use the result fomr vacuum, but not work with database create from dump before or after vacuum.

Error is "table licenses already exists"

The Dreamer.

 

[marino]

Why is this topic still pinned? It appears to be entire a moot point now. The support for pkg_* tools has been removed on all supported platforms.

 

[kpa]

There might be some people still using the old tools by maintaining them by themselves but none of them have showed up here in the last year or so. I think it's time to unpin it, people who want to use the old tools are on their own anyway.

 

[lme@]

Why is this topic still pinned? It appears to be entire a moot point now. The support for pkg_* tools has been removed on all supported platforms.

Thanks, I removed the sticky bit!

 

[junovitch@]

marino, thanks for pointing this out. If you are hanging around here being helpful someone is going to need to give you your "developer" tag and "@" on your name. Hint hint lme@.

 

[lme@]

Done!