Package daemon refuses to install some devel packages

[haiqu]

I've been getting consistent errors trying to install development packages. The typical error mesage is something like this (when double-clicking on the package in ~/packages):

The following additional package changes have to be made:

'''in system:'''

install package fftw_x86-3.3.4-4-x86_gcc2.hpkg from repository HaikuPorts
install package fftw_x86_devel-3.3.4-5-x86_gcc2 from repository local

Note that the first package is already installed and shows up in the /boot/system/package_links directory. It resides in /boot/home/packages and was installed by using a macro that copies from haikuports/packages to ~ then moves the file to ~/packages so that the daemon has enough time to install it (per online instructions).

If I do the same thing with fftw_x86_devel I get a different error:

The following problems have been encountered. Please select a solution for each:

'''Package fftw_x86_devel-3.3.4-5 requires libfftw_x86==3.3.4, but none of the providers can be installed'''

[] -solution 1:
Allow downgrade of fftw_x86-3.3.4-5 to fftw_x86-3.3.4-4
[] -solution 2:
Don't activate package fftw_x86_devel-3.3.4-5

[] Ignore problem for now

In short, none of the provided solutions are really useful.

At times rebooting the system fixes the issue but in this - and several other - cases it didn't help.

[bonefish]

On general note: Please always provide a syslog in case of package installation issues. It also helps, if you start your narrative from a known consistent state and describe exactly what you do. From the output I assume that in the first case you're trying to install package fftw_x86_devel-3.3.4-5-x86_gcc2 in system. For the second output you mention the same package, but not which version -- I assume the same. It is also not clear to me how or if both outputs are chronologically related.

You mention that in the first case fftw_x86-3.3.4-4-x86_gcc2.hpkg is already installed in home. If you, however, install a package that requires fftw_x86-3.3.4-4 in system, that is irrelevant. system is an installation location that needs to be consistent and self-contained. Hence the dependency solving algorithm suggests to install the required dependency in system (even if that duplicates a package in home). So the first part works as it should.

In the second case I assume the issue is simply that the dependency declarations in the recipe are inconsistent. The ​devel package requires libfftw_x86==3.3.4, but the ​main package no longer provides it.

On a related note: It is not a good idea to replace an older revision of a main and devel package pair with a new revision by replacing the packages one by one. Dependency declarations may change in an incompatible (but consistent) way. The same goes for any set of dependent packages, of course. It would be better in such a situation to replace all concerned packages at once. pkgman can do that. Not sure about HaikuDepot -- if not, it would be worth a feature request.

[haiqu]

OK, I'll write this slowly so you can understand it.

Reply to Para 1: Here's the syslog tail, from the time the package was built until after installation. It's useless in this case.

KERN: package_daemon [2557590216:  6638] Volume::_PackagesEntryRemoved("fftw_x86-3.3.4-5-build.hpkg")
KERN: package_daemon [2557612444:  6638] CommitTransactionHandler::_ChangePackageActivation(): activating 0, deactivating 1 packages
KERN: packagefs [2557632288:  6638] Volume::_ChangeActivation(): 0 new packages, 1 old packages
KERN: packagefs [2557632801:  6638] package "fftw_x86-3.3.4-5-build.hpkg" deactivated
KERN: package_daemon [2558591575:  6638] Volume::_PackagesEntryRemoved("fftw_x86_devel-3.3.4-5-build.hpkg")
KERN: package_daemon [2558613875:  6638] CommitTransactionHandler::_ChangePackageActivation(): activating 0, deactivating 1 packages
KERN: packagefs [2558633009:  6638] Volume::_ChangeActivation(): 0 new packages, 1 old packages
KERN: packagefs [2558633506:  6638] package "fftw_x86_devel-3.3.4-5-build.hpkg" deactivated
KERN: package_daemon [2559455857:   454] volume at "/Work/haikuports/sci-libs/fftw/work-x86-3.3.4/boot/system" unregistered
KERN: package_daemon [2559456334:   454] root at "/Work/haikuports/sci-libs/fftw/work-x86-3.3.4/boot" unregistered
KERN: package_daemon [2568745392:   463] Volume::_PackagesEntryCreated("fftw_x86-3.3.4-5-x86_gcc2.hpkg")
KERN: package_daemon [2575319471:   463] CommitTransactionHandler::_ChangePackageActivation(): activating 1, deactivating 0 packages
KERN: packagefs [2575322296:   463] Volume::_ChangeActivation(): 1 new packages, 0 old packages
KERN: packagefs [2575324252:   463] package "fftw_x86-3.3.4-5-x86_gcc2.hpkg" activated
KERN: package_daemon [2576185650:   463] KERN: Volume::_PackagesEntryCreated("fftw_x86_devel-3.3.4-5-x86_gcc2.hpkg")

I have just built and installed fftw_x86-3.3.4-5 and am trying to install fftw_x86_devel-3.3.4-5 (which was built at the same time) but the package daemon refuses to recognise it.

Para 2: I have not installed fftw_x86_3.3.4-4 and I have no idea where you got that idea. The package daemon wanted to downgrade to fftw_x86-3.3.4-4 for some reason. The dependency solver should check for the presence of the package in ~/packages and if present accept it, not try to install it elsewhere. That part is just nuts.

Para 3: The dependency declarations in the recipe are consistent, but there's a catch. The package .so file extensions (3.4.4) don't match the package version (3.3.4) However, this should NOT be an issue since the recipe PROVIDES fftw_x86-3.3.4 which is all fftw_x86_devel-3.3.4-5 REQUIRES. If it's looking at individual lib names, it's going beyond what the recipe defines and is exceeding its authority.

Para 4: Rant ignored, irrelevant in this case. There was no pre-existing version on the system.

Addendum: I note that once again a bug report has been prematurely closed. I'm pointing out a single, genuine and obvious case where this system doesn't work which you can test for yourself and see easily. I have many more examples, such as packages not being recognised unless they're installed in /boot/system/packages and so on. It's pretty broken, but just keep believing it's fine and it might all go away.

[waddlesplash]

I have just built and installed fftw_x86-3.3.4-5 and am trying to install fftw_x86_devel-3.3.4-5 (which was built at the same time) but the package daemon refuses to recognise it.

Yes, this is because of the issue in the recipe that @bonefish mentioned.

Para 2: I have not installed fftw_x86_3.3.4-4 and I have no idea where you got that idea. The package daemon wanted to downgrade to fftw_x86-3.3.4-4 for some reason. The dependency solver should check for the presence of the package in ~/packages and if present accept it, not try to install it elsewhere. That part is just nuts.

This is the same issue: the older version of the package does not have the mistake in it. It can't accept the already-present version because it does not have the correct PROVIDES/REQUIRES/etc.

Para 3: The dependency declarations in the recipe are consistent, but there's a catch. The package .so

No, the package_daemon doesn't care about what the sonames are in the package. The issue is with the devel package's REQUIRES, as stated above.

Addendum: I note that once again a bug report has been prematurely closed. I'm pointing out a single, genuine and obvious case where this system doesn't work which you can test for yourself and see easily.

The system works just as it is designed. There is a bug, yes, but it's in the fftw3 recipe at HaikuPorts, not here.

We might be able to improve our error messages, though. That could be a real problem that is package_daemon's fault.

[bonefish]

Replying to haiqu:

waddlesplash already replied to most of your points, so I'll only add a few bits.

OK, I'll write this slowly so you can understand it.

If writing slowly helps you to provide complete and consistent bug reports, then that's much appreciated.

Reply to Para 1: Here's the syslog tail, from the time the package was built until after installation. It's useless in this case.

If you hadn't truncated it, one would be able to see what packages were installed at boot time, whether the installation locations were consistent then, and what package operations had been performed since. This is very relevant information for issues related to package installation. It is no longer relevant for this ticket, as I was able to piece things together sufficiently even with the limited information you provided; that's why I started the paragraph with "On general note".

Para 2: I have not installed fftw_x86_3.3.4-4 and I have no idea where you got that idea.

I got that idea from your description. You wrote

"Note that the first package is already installed and shows up in the /boot/system/package_links directory."

The first of the two packages mentioned was fftw_x86-3.3.4-4.

The package daemon wanted to downgrade to fftw_x86-3.3.4-4 for some reason.

No, it did not. It additionally want to install fftw_x86-3.3.4-4 in system, because it -- or any other package providing what was required by the package you requested to install -- wasn't present there yet.

The dependency solver should check for the presence of the package in ~/packages and if present accept it, not try to install it elsewhere. That part is just nuts.

As I already explained, the point is to keep the system installation location consistent. Why we want that should be obvious when you think about a multi-user setting. It also makes sense in a single-user setting e.g. with respect to safe modes that disregard packages installed in home.

Addendum: I note that once again a bug report has been prematurely closed. I'm pointing out a single, genuine and obvious case where this system doesn't work which you can test for yourself and see easily.

The information you have provided show only one issue, which is a bug in the package declaration and thus belongs to HaikuPorts. Please feel encouraged to report a bug there.

I have many more examples, such as packages not being recognised unless they're installed in /boot/system/packages and so on. It's pretty broken, but just keep believing it's fine and it might all go away.

Feel free to report those issues, but please provide sufficient information.

Replying to waddlesplash:

We might be able to improve our error messages, though. That could be a real problem that is package_daemon's fault.

In case of dependency solving issues, the problem and solution analysis comes straight from the dependency solver library (libsolv). We could add more information in some situations, e.g. in this case what the providers of "libfftw_x86==3.3.4" are and why they cannot be installed. However some of that information (in this case the latter part) can be hard to come by and may be fairly complex. It would most likely be useful only to developers, who should be able to use pkgman (which has a debug mode) anyway.

[haiqu]

Seems I've found the solution. It was *yet another* recipe error.

Package fftw_x86_devel REQUIRES libfftw_x86, but fftw_x86 PROVIDES libfftw3_x86. Should have been REQUIRES fftw_x86.

Sorry to get a bit cranky but I've literally fixed hundreds of these errors and it gets fairly tedious.

Apologies to Ingo, the package daemon is not to blame here.

[haiqu]

Well that should have fixed it, but didn't. Damned if I know what's going on with this thing.

[waddlesplash]

Package fftw_x86_devel REQUIRES libfftw_x86, but fftw_x86 PROVIDES libfftw3_x86. Should have been REQUIRES fftw_x86.

Yes, that's what we've been telling you this whole ticket.

[haiqu]

That error I found was indeed the problem, it just took the system the usual two-installs-and-a-reboot to find the package after I corrected it.

The very next library I needed (vigra) also had a very broken recipe. How in heaven's name a recipe can get to version 6 and still not work at all is beyond me. Well no it isn't, I know exactly what's going on. The guys who write them just don't test their work because they think they know everything.

Many of the comments above deserve a response, but there's not much point. This will be my last bug report, I'm sick of the condescending bullshit I get in response. If you think I hadn't already spent days looking for the error in that recipe, you have rocks in your heads.

[diver]

fftw recipe is fixed now. An updated package should be uploaded though.

[humdinger]

Updated fftw packages with hrev49469.