Den 13:27 21. april 2012 skrev Alexey Tourbin <alexey.tour...@gmail.com> følgende: > On Fri, Apr 20, 2012 at 5:16 PM, Jeffrey Johnson <n3...@me.com> wrote: >> The methods in the existing encoding/decoding are in rpmio/set.c @rpm5.org: >> the algorithm >> is unchanged from Alt. >> >> A change to the existing scheme over the next few months doesn't bother >> me at all. But "legacy compatibility" has instantly appeared as an issue >> for an @rpm5.org implementation that has been "working" for less than >> 24 hours, and where the need is to attempt to install Alt packages >> into a chroot, sounds like @rpm5.org is going to be forced to both >> "old" and "new" encodings merely to continue trying to do "continuous >> integration" >> with Alt packages. >> >> But "legacy compatibility" is an insoluble problem which need not be >> discussed. >> If there's a better encoding scheme available soon, then switching is >> better done earlier than later. > > The amount of compatibility with the existing Alt format is > negotiable. If you think that rpm5 must be able to install Alt > packages into chroot, then there is little choice but to 1) design the > new format with a clear distinction, so that older set-strings don't > get confused with the newer ones; and 2) to provide an additional > decoding routine. However, no additional support is required in e.g. > the comparison routine, since the decoding routine simply restores the > array of hash values. So this doable. > > There another option, however. For the reason which shall remain > nameless, I find it tempting to produce the new and incompatible > format without any clear signs of distinction. :-) > >> ATM, rpm-5.4.9 does only doing decoding (and comparison) of set:versions. >> The need was to be able to install Alt sisyphus packages (with set:versions >> dependencies) >> into a chroot. Generating set:versions (Alt uses a helper script, "multilib" >> packaging needs >> to use the gelf* API) will be harder, particularly if interoperability is >> desired. > > Using gelf* API probably won't do, since it is best to use > ldd(1)-based tool which will basically invoke ld.so(8) to resolve > symbols and dump associations between the symbols and the libraries. > It can't be easily done with *gelf ABI, unless you actually try to > reimplement a substantial portion of the dynamic linker, which is a > bad idea anyway. So using the script is the only realistic options. If > the script cannot be used at all (i.e. due to issues with multilib > attributes), this probably indicates a problem within rpmbuild itself. > >> But set:versions looks quite useful, and far more effective at reducing the >> number >> of dependencies than attempting a "pin-hole" optimizations with boolean >> expressions, discarding inequalities which are implied by other dependencies, >> as Per Oyvind has been attempting in Mandriva. > > Where can I find more information about this work? http://svn.mandriva.com/viewvc/packages/cooker/rpm/current/
Notice that pretty much all of the work related on this has been done outside of upstream, with much regard for it in the more experimental patches adding new functionality like this, hence the code certainly would need to be cleaned up, refactorized and sanitized before even being considered being pushed anywhere else than - ø-ø-øø-øøøpppppppppppppppøpppøøøøpøøø pppppppppppppppppøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøø øppppp ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
