On Wed, Sep 19, 2018 at 03:25:36PM +0300, Panu Matilainen wrote: > On 9/19/18 12:23 PM, Panu Matilainen wrote: > > On 8/23/18 12:01 AM, Vladimir D. Seleznev wrote: > >> You convinced me that there should be whitelist filter, so I rewrote > >> code for it. Follow Panu suggestion [1] I wrote .C generator to filter > >> proper rpm tags. > > > > Sorry for the terribly late response, I keep intending and intending and > > somehow almost a month passed :(
It's OK, I was busy too. > > Also shows that its a while since the initial discussion: I don't recall > > suggesting that :D but nevermind. > > > > Another possibility that wouldn't need a separate generator script would > > be just including that info in the tag table itself, similarly to how > > "extension" is there, although I think there's no API to access it ATM > > (another idea that was never finished). Might as well make it a flags > > bitfield where we can cram such stuff and rpmTagGetFlags() or so to > > fetch the data... > > > >> But currently it does not allow this suggestion [2] by > >> jbj@: > >> > >> "The members (and ordering) of the IDENTITY tag set might also > >> need to be configurable without recompiling." > >> > >> Currently I have no idea what is better way to do that. May be one of > >> solution can be to define some macro that contains tag that should be in > >> calculation, but this doest seem to be convenient and practical. > >> > >> Also its value may be needs a prefix for versioning tag value. When new > >> tags are marked to be involve to calculating the prefix changes. I think > >> the prefix should also include a vendor identifier e.g. fc, alt, mga, > >> suse etc. > > > > I dunno why it should be vendor specific, we rather try to avoid such > > things in the first place. Ok, but I think there can be vendor specific. And I still don't realize better solution to filter tags. > >> While here is marker for tags that values should be involve to identity > >> calculation, I think here should be special case for some of string > >> array tags: a marker for processing array before calculation. For > >> example, we want to filter some of value from package provides but we > >> don't want to exclude the whole array from identity calculation. I think > >> it could be done with one more marker with argument of array processing > >> function that return (char *) — the result of string processing. There > >> is difficulty that RPMTAG_PROVIDE* is three separate tags and I have no > >> idea how to take it in consideration. > > > > Why do you want to filter provides? > > Okay it was mentioned at least in here: > https://github.com/rpm-software-management/rpm/issues/426 : > > >> P.S. Since RPMTAG_RELEASE is supposed to be filtered, there is > >> sense to filter some elemenents of package RPMTAG_PROVIDE* and > >> RPMTAG_REQUIRE* > > I dont see how you could meaningfully filter RPMTAG_RELEASE, it can be > (and often is) embedded in any number of places where you cannot > possibly know whether it was originally hardcoded to that value or if it > came from RPMTAG_RELEASE. Mm, that is a problem too. ALT rpm packages release generally doesn't contain things that are depend on build environment, but other RPM-based distos generally use %dist in their package release. I don't know now how to solve this on right way, but, for example, the calculation logic cat replace every RPMTAG_RELEASE value to nothing in provides, requires, conflicts etc tags. And that %dist seems to be one of vendor specific despite of the fact this is a mainstream. So, I need advises for better solutions for implementation of which tags should be included for identity calculation and what to do with cases such as RPMTAG_RELEASE environment depended contents. -- With best regards, Vladimir D. Seleznev _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint