On Mon, Jul 2, 2012 at 9:17 AM, Jeffrey Johnson <n3...@me.com> wrote: >> 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.
It was a long time ago, but it was not that bad. In ALT Linux we still use rpm-4.0 code base (with many important backports etc.). Since I've recently broken with ALT Linux, I cannot make more claims, you see... > 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. I don't like how "multilib" works either. You can no longer identify packages by their names, and then there are special rules to resolve file conflicts, which basically say that the license is that you can swamp files as much as you want, provided that you got the first hand in that strange "x86-64" relationship. There is than that recent "x32" stuff where you can run in 64-bit mode using only 32-bit pointers. How can you address THAT? To me, the world is declining, like the Roman Empire. ;-) >> 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."? Our basic task, is that when we feed packages to rpm(1), it must quickly decide whether the upgrade is feasible or not. Of course this involves hard and sometimes speculative considerations whether things are going to work. But if things are definitely not going to work, rpm should upgrade never! Not without a special flag which reads '--upgrade-as-i-wish'. What is not part of "our basic tasks" is to find an upgrade plan. How they do that - it's another business, and completely another story. We only check if the upgrade is consistent or not. > 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". I realize that the "version" is somehow a contrived concept behind really a containter. Like: - Whats' that? - It's a version. - Oh my gosh! But then again, if you try to organize your thinking beyond sets, bytes, and characters, the concept of "version" pops up pretty naturally. If we are going to satisfy some requirement, that's good for "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. Not all subset operations are equally important, or complex. As I said, sometimes you should make easy things easy, and simply use <std::set> which is Rb-tree or something like this. Sometimes things go off, though. Like this: - How many symbols do you want to encode? - 10M. - That's a lot, are you ready to pay? - No. - That's not serious, are you ready to pay at least 2 characters per symbol? - Well, probably. ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
