Hi, I'm primarily responding to your proposed pkg_postinst_ontarget_${PN}, as I'm a little bit worried. * Alexander Kanavin <alexander.kanavin@...> [170214 15:04]: Mark Hatle should

I checked this with the master branch (e.g. current rpm5/smart behavior). They are *not* run under set -e, and no amount of bogus failing nonsense prior to that last chown command will make the

I think there is an assumption that these postinstalls are run under set -e which may or may not be the case, I really don't remember. I do agree that if these are not run under -e, they are broken

I found an example where qemu *is* called directly from postinst - in eudev and systemd recipes. Unfortunately, they're both broken: pkg_postinst_eudev-hwdb () { if test -n "$D"; then

I guess you meant the postinsts provided by fontcache.bbclass and other *cache.bbclass files? Those postinsts do not actually call qemu, and so will *not* fail in any circumstances. What they do is

I'm not sure I agree with this. I do understand your concerns however its not quite as clear cut as you make out. We have situations where we simply don't know in advance if a given postinst is going

Yes, although I have not verified this. Alex

Does pkg_postinst_ontarget_PACKAGENAME() work with other package managers like opkg?

Hello, I've posted the patchset for replacing the smart package manager with dnf package manager to oe-core list, and wanted to write a separate email here, laying out what are the changes this will

Postdoc position available for our new FET-PROACT project https://ssl1.peoplexs.com/Peoplexs22/CandidatesPortalNoLogin/Vacancy.cfm?PortalID=3795&VacatureID=884160 The Embodied AI and Neurorobotics

I just realized that my disk footprints where off. The actual libsolv footprint is about 3 times my original estimate. Here are the correct metrics: ======================== Disk

SDR devroom starts at 1030, I'll try and be at the stand before then. Beer event willing. Philip

I try to be there at 9:00 (have ~3h by car) - anybody there then? Andreas

Static codesize it one aspect, it will also be interesting to know the runtime memory requirements changes due to this. Since that could also be a concern for systems using opkg.

I think it's a bit easier for desktop distros. The upstream developers have to use some kind of desktop Linux, and then it's natural that they would be supporting their distro in packaging and

Also, the upcoming dnf repo manager is also using libsolv. So any bugs and issues will at least be consistent across packaging backends :) Alex

I for one endorse this plan. Solving isn't trivial, so sharing code is wise. Ross

Before opkg 0.3.1, dependency solving was performed exclusively by an internal recursive ad-hoc solver implementation. On version 0.3.1, an alternative external solver backend was introduced, based on

The reply should be "Hey, send a patch". We will never get around that issue. The depends on the package. If there are any pending upstream patches, those may need to be ported forward if not

F25 is still on openssl-1.0.2j and from the one person who replied on freenode #fedora, there don't seem to be any plans to upgrade. The ABI checker site has check on 1.0.2k and claims: Backward