[packages/chromium-browser] requires _XGetRequest

Jeffrey Johnson n3npq at me.com
Mon Nov 11 22:39:20 CET 2013


On Nov 11, 2013, at 4:07 PM, Michael Shigorin wrote:

> On Mon, Nov 11, 2013 at 10:28:34AM +0100, Tomasz Pala wrote:
>>>> Maintaining symbol lists for rpm automation would require
>>>> probably too much effort.
>>> but if it's just pairs of such detections, so if you find 
>>> incompatibility, you register it once, and all packages being built with 
>> There is a tool that checks that:
>> http://ispras.linuxbase.org/index.php/ABI_compliance_checker
>> which lists added symbols:
>> http://upstream-tracker.org/compat_reports/libssh2/0.18_to_1.0/abi_compat_report.html
>> so it makes it easier to do automated scans for non-versioned
>> symbols that were added without SOVER++ in order to put this
>> into R to be automatically pulled on upgrade.
> 
> There's also set-versions implementation in ALT-RPM but I doubt
> it's directly portable to rpm5 with no sacrifices, at least in
> short term.  That one creates fingerprints of ABI provided and
> required to match these when resolving dependencies.
> 

Not true: the set:versions dependency resolution is fully
wired and tested by installing ALT linux into a chroot.

The generation of set:versions has not been done solely
because of lack of interest from ALT, ROSA, Alexey Tourbin
(the original implementer) and others.

I personally think that the ALT set:versions should be used by
distros based on RPM.

OTOH, the addition of a new dependency type (and resolution)
like set:versions takes some careful planning by distrosx.

> *Maybe* parts of implementation/tools or concept will help you.
> 

Please supply the pointer to the original paper (in Cyrillic, I've
managed to read the details with GOOG translate, perhaps
others can read the Russian).

hth

73 de Jeff

> -- 
> ---- WBR, Michael Shigorin / http://altlinux.org
>  ------ http://opennet.ru / http://anna-news.info
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



More information about the pld-devel-en mailing list