On Jul 1, 2012, at 11:43 PM, Alexey Tourbin <alexey.tour...@gmail.com> wrote:
> On Sat, Jun 23, 2012 at 10:29 PM, Jeffrey Johnson <n3...@me.com> wrote: >> In the interest of getting off negative nerdy obscure discussions, let's >> try a positive alternative application for Golob-Rice subset operations. >> >> All RPMv4 packages attach (a lightly filtered) file(1) magic string to >> every file. > > All RPMv4.4+ packages, that is, but not RPMv4.0. I find this "file > coloring" business very annoying, by the way, and it took me some time > to realize that "fc" actually stands for "file coloring". :-) > RPMv4.0 was a l-o-n-g time ago. I find multilib quite annoying: I was asked for an implementation, and did so. 'Twas a job mon: already 7y since leaving @redhat, and file colors for multi lib were several years before that. And the "fc" stands for "file classifier". But feel free to claim whatever you want just like everyone else. >> The file(1) data is mostly usable as a "keyword" namespace exactly as is. >> Yes there are flaws: however magic strings are from file(1) is about >> as good as any other de facto keyword tagging of file content. >> >> keywords are strings just like elf symbols are, and set:versions (or Bloom >> filters) >> are a compact representation from which its rather easy to do subset >> computations. >> >> One extension that would be needed is a "closest" metric in order to >> "prefer" >> the largest subset overlap: with set:versions any contained subset will >> satisfy the >> logical assertions, and there's no easy way to prefer the larger sub-set. > > I see no reason why rpm(1) should ever consider any preferences. To > me, rpm(1) is exactly black-and-white thing, a watchdog which checks > logical assertions. Things are either consistent enough to proceed > (and e.g. to upgrade the packages), or not - and then you get e.g. > non-zero exit code and you are forced to bail out. Higher-level logic > of finding an upgrade plan anyways belongs to something like apt(1) or > yum(1), although it is executed in some basic librpm terms which we > must make efficient enough. I see no reason to discuss closest metrics > or largest overlaps - this is as interesting as irrelevant to our > basic tasks. Everyone has an opinion: yours is particularly brittle but entirely logical. Now go persuade everyone else that your opinion is The One True Opinion and RPM will surely change too. > >> There's a similar application with dual/triple/... licensed software and >> computing >> per-file, not per-package, license affinity precisely where set:versions (or >> Bloom >> filters) will represent keywords (like "LGPLv2" or "BSD") easily. Licenses >> unlike >> file(1) magic keywords will require name space administration. SUrely LSB >> and LFF >> are seeking something useful to do for RPM packaging these days, and might >> be convinced to make some set of license tokens "standard" so that license >> affinity can be precisely computed in distributed software. > > You then discuss more applications which are largely irrelevant to our > basic tasks. (I realize that I'm revisiting and older discussion, > which might not be completely fair because our understanding might > have evolved since.) > Um … what are "… our basic tasks."? I cannot determine what is "fair" without knowing what is being compared … > Anyway, set-versions are not the "next big thing" with plenty of > applications. It's rather a very boring stuff which nevertheless > answers the question "how we can possibly enhance ABI compatibility > control beyond sonames". The answer is that we must involve into > set/subset testing - that's the model, that it is very expensive, and > that the only reasonable and possibly the best way to go is to replace > symbols with numbers, and to treat sets of numbers as special kind of > versions. Now why is that? But that's a much better perspective for > discussion. We differ in usage cases. I see a "container", you see a "version". There are many usage cases for subset operations in "package management" no matter what we think or how the operations are implemented and represented. 73 de Jeff > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-devel@rpm5.org ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
