pkgng: pkg upgrade

S

sovking

Hi,
I switched a freebsd 9 system to pkgng.

I've noticed this problem:

On this system apache22 and php5 are installed, with php5 some config options changed - e.g. to work with apache as integrated module.

If I run pkg upgrade

I get:
Code: 
Repository catalogue is up-to-date, no need to fetch fresh copy
The following packages will be upgraded:

        Reinstalling php5-5.4.7

The installation will free 11 MB

0 B to be downloaded

Proceed with upgrading packages [y/N]

I don't know why it want to reinstall php5, but if press 'y', it reinstall php5 with the standard options and of course it deletes the php5 apache module.

This is not what I want, and I think it is the correct behavior.

The behavior should be:
1) check if php5 version of the remote repo is greater than the local php5 version;
if so go to 2)
2) If the configured options are different from the standard options, upgrade by fetching a binary versions with the same options or by building the new version using ports.

I'm correct or I'm missing something ?
Maybe this a current limitation of pkgng ?

Any help could be appreciated!
 
Build your own package repository or make sure you build php5 from ports.
 
zeissoctopus said:
The remote repository is not sync with the latest port tree
Click to expand...

This is not the problem. The current PKGNG implementation does not yet support restricting the installation of packages to ones compiled with certain options. Also the repositories that are now available are compiled with the default options just like the old ones are.
 
zeissoctopus said:
The remote repository is not sync with the latest port tree
Click to expand...

I think the remote repository if a package has version x.y.z with is lower than what is present in an updated ports system: but this is not the case because the version is the same.

SirDice said:
Build your own package repository or make sure you build php5 from ports.
Click to expand...

This will work, but however it's not a big deal if you have few machines with different packages some of them built on ports.
I think pkgng, as package manager - e.g. not a ports management tool -
should detect when an installed package is built from ports or get as is from a package repository.
In the former case let the user to use a port management tool to upgrade, while in the former case upgrade from the package repository.
Now the problem is that it does not detect this and tell you to upgrade... but it should not or should give you some different message.
 
sovking said:
I think pkgng, as package manager - e.g. not a ports management tool -
should detect when an installed package is built from ports or get as is from a package repository.
In the former case let the user to use a port management tool to upgrade, while in the former case upgrade from the package repository.
Now the problem is that it does not detect this and tell you to upgrade... but it should not or should give you some different message.
Click to expand...

The only thing it could do is to scan /var/db/ports and warn you that a package you want to upgrade has been installed via ports. It would be very difficult to see if there are any differences because it would need to maintain a database with all the default options of a port and compare them with the ones it finds in there.

The best thing currently is to use either ports or packages and not mix them unless you really know what you are doing, the order and the method in which you have to upgrade each.
 
sovking said:
I think pkgng, as package manager - e.g. not a ports management tool -
should detect when an installed package is built from ports or get as is from a package repository.
Click to expand...
And there's the problem. There is no difference between a port and a package once it's installed. So how could the system tell the difference?
 
SirDice said:
And there's the problem. There is no difference between a port and a package once it's installed. So how could the system tell the difference?
Click to expand...

Well, I think this information could be stored in the local repository.

When I install a package using ports, the port system update the local pkgng repository, it should add the following information:
a) the port has been built locally or not
b) the signature of the build (e.g. root@xxx.yyy.zz on 31/12/2022).
With these two pieces of information and the version the pkgng system could argue the difference, in particular:
1) local built package or repository downloaded package, and
in the case we are comparing two packages of the same origin (local o from repository)
2) the unique signature let to distinguish the packages.

This lets the user to chose what to do when upgrading packages.

Of course other solutions can be proposed.
 
gkontos said:
The only thing it could do is to scan /var/db/ports and warn you that a package you want to upgrade has been installed via ports. It would be very difficult to see if there are any differences because it would need to maintain a database with all the default options of a port and compare them with the ones it finds in there.

The best thing currently is to use either ports or packages and not mix them unless you really know what you are doing, the order and the method in which you have to upgrade each.
Click to expand...

This latter sentence now applies to anyone wishing to test-install or test-upgrade to CURRENT? Is that not a showstopper of some sort VS the usage of FreeBSD (for semi-newbies) as implied by 90 percent of the online guides and documentation? OR some succint flowchart with instructions on how to proceed to solve common issues should be referenced in both UPDATING? (Sorry to lead the thread a bit off of its main topic...)
 
gkontos said:
The only thing it could do is to scan /var/db/ports and warn you that a package you want to upgrade has been installed via ports. It would be very difficult to see if there are any differences because it would need to maintain a database with all the default options of a port and compare them with the ones it finds in there.
Click to expand...

I would prefer to improve pkgng by exploting the sqllite functionality (just add one or two column to the db table), than slowly interacting with the filesystem.

gkontos said:
The best thing currently is to use either ports or packages and not mix them unless you really know what you are doing, the order and the method in which you have to upgrade each.
Click to expand...

I do not agree.
Maybe that could be ok for the desktop user or casual user. Using only packages is like to not have OPTIONS in ports. Using only ports can be a waste of time, because sometime we need to specialize only a subset of packages.

But the most important thing: if I issue the command 'pkg upgrade' I do not want receive erroneous answer, like a package that should be ``upgraded'' to the same version which can stop my system from working correctly (php5 without apache module, on a web server will stop any php based page).

For this specific case probably another simple solution could be to split the package in more packages:
- php5 (language only)
- php5-apache-module (which require that php5 is installed).

IMHO, php5 apache module should be a small package dependent on php5, not an ``option'' of building php.
 
sovking said:
For this specific case probably another simple solution could be to split the package in more packages:
- php5 (language only)
- php5-apache-module (which require that php5 is installed).
Click to expand...
Which is going to pose a problem, it will need to be specifically compiled for a certain web server, and we have several. Which is the primary reason why the module has been turned off by default in the first place.
 
SirDice said:
Which is going to pose a problem, it will need to be specifically compiled for a certain web server, and we have several. Which is the primary reason why the module has been turned off by default in the first place.
Click to expand...

You are right: several web server are supported.
But :)
- FreeBSD has over 22K ports and apache+php is used on a big amount of FreeBSD installation;
- FreeBSD have a variety of minor packages available, so having an apache+php library available as separate package would not hurt anyone and would be useful to the same ``big amount of FreeBSD installation''.

However this separate package could be another topic maybe to be discussed on the appropriate mailing list (freebsd-ports ?).
 
sovking said:
You are right: several web server are supported.
But :)
- FreeBSD has over 22K ports and apache+php is used on a big amount of FreeBSD installation;
- FreeBSD have a variety of minor packages available, so having an apache+php library available as separate package would not hurt anyone and would be useful to the same ``big amount of FreeBSD installation''.

However this separate package could be another topic maybe to be discussed on the appropriate mailing list (freebsd-ports ?).
Click to expand...

A solution to this problem would be to use package "flavors" with a few common options. But lets wait for the thing to become the official package manager first.
 
The flavors could be sets of requirements for set and unset options. For example for the PHP port the "APACHEMODULE" flavor would be simply (quickly invented ad hoc syntax):

Code: 
require APACHE set

These requirements could be then matched against the remote repository and if a package with matching options is found it's installed, otherwise a port is compiled with the required options settings.

Isn't gentoo doing something like this already?
 
I found OpenBSD flavors for a popular package and it was more convenient than the same thing on FreeBSD that had to be installed from ports after configuring out some unwanted options. But what if someone wants a set of options not found in flavors ? There would be too many packages/flavors!
Can pkgng help working with ports, build a port with custom options but recursively fetch and add the required packages that don't need make config?
 
silicium said:
Can pkgng help working with ports, build a port with custom options but recursively fetch and add the required packages that don't need make config?
Click to expand...

That's the point: pkgng is built to deal with packages, but when a package is missing or a is required with not standard options should interact with a port-manager too; the same using your words: pkgng help working with ports and when a standard package is available it should fetch it.
 
Pkgng will never interact directly with the ports tree and with a port-manager tool, it is a binary only tool, with helper to allows the ports tree and the ports tools to interract with it (not the other way around).

To solve this now: a tool pkgng aware has to be written or portupgrade/portmaster/portbuilder needs to be improved.

Concerning the problem, php5 is reinstalled because the remote repository has different options from the one locally installed, it considers the remote repository is always right (probably optionnify this behaviour could be done in pkg.conf, but such an option does exists yes).

With the new solver, pkgng will only act like this on the first repository, so one would have to create its own repository for packages manually rebuilt, and set pkg.freebsd.org has a second one (aka fallback).
 
You must log in or register to reply here.
Back
Top