On Apr 21, 2012, at 7:27 AM, Alexey Tourbin wrote:
> 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.
>
Negotiable is good (but I'm really hoping to be entirely Alt compatible
if/when I pursue generating set:versions encodings @rpm5.org: see the issue
below).
I'd like to avoid the LZMA <-> XZ fiasco. The deployment took 3+ years,
SuSE adopted LZMA too early, and now RPM is stuck with both LZMA
and XZ support for reasons that have to do with SuSE's long term
support and nothing whatsoever to do with RPM packaging.
But "legacy compatibility" discussions for an implementation that
started a couple of week's ago and reached a "continues integration"
buildbot 48 hours ago is premature (and WILL deprive the "bikeshed"
of months of salacious gossip about @rpm5.org "incompatibilities" needlessly).
> 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. :-)
>
A new RPM format or a new set:version encoding format?
>> 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.
>
Um, dunno where you and Alt have been for most of this century, but
RPM abandoned ldd(1) almost 10y ago and isn't going to revert from
using the gelf* routines for any of the reasons you just stated.
We can waste time arguing about "substantial" and "bad" and "realistic"
if you wish.
Or we can discuss the fundamental difference that ldd(1) performs that
can only be partially implemented using gelf* routines.
The core issue has to do with identifying the SONAME for "legacy compatibility".
Older (and newer/broken libraries) do not have a DT_SONAME field in
ELF metadata. Instead symlinks are the _ONLY_ means of attaching
an SONAME to a library without a DT_SONAME . Libraries with DT_SONAME
generate symlinks by rule based on the information in the existing ELF
DT_SONAME in metadata.
SInce gelf* has methods only for processing ELF metadata, there is insufficient
context (in a %{buildroot} image of the actual installed file system) to attempt
to do exactly what ldd does.
Otherwise, everything else already implemented in rpmlib faithfully
mimics the needed parts of the dynamic loader sufficiently well to generate
ELF dependencies without using ldd(1), known good, already done,
works, etc.
>> 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?
Well there's not a whole lot going on. Attached is the section of code (in
lib/rpmfc.c)
that I am *ahem* generously calling "peephole optimization" in its entirety.
Doing expression optimization on boolean expression's generally is a very
different
problem, and would need compound logic and transforms to sijunctive normal
form and more that are likely better left to a SAT solver implementation than
attempting expression optimization (aka removing assertion redundancy).
hth
73 de Jeff
========================= lib/rpmfc.c:522 in rpmfcHelper()
...
#if defined(RPM_VENDOR_MANDRIVA) /* filter-overlapping-dependencies */
int overlap = 0;
if (*depsp) {
int ix = rpmdsSearch(*depsp, ds);
if (ix >= 0) {
EVR_t lEVR = rpmEVRnew(RPMSENSE_ANY, 0),
rEVR = rpmEVRnew(RPMSENSE_ANY, 0);
rpmdsSetIx(*depsp, ix);
rpmEVRparse(rpmdsEVR(*depsp), lEVR);
rpmEVRparse(EVR, rEVR);
lEVR->Flags = rpmdsFlags(*depsp) | RPMSENSE_EQUAL;
rEVR->Flags = Flags | RPMSENSE_EQUAL;
if (rpmEVRcompare(lEVR, rEVR) < 0) {
(*depsp)->EVR[(*depsp)->i] = EVR;
(*depsp)->Flags[(*depsp)->i] = Flags;
overlap = 1;
}
lEVR = rpmEVRfree(lEVR);
rEVR = rpmEVRfree(rEVR);
}
}
if (!overlap)
#endif
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
