On Mon, May 23, 2011 at 21:13, Jeff Johnson <n3...@mac.com> wrote: > > On May 23, 2011, at 7:30 PM, Robert Xu wrote: > >> On Mon, May 23, 2011 at 18:27, Jeff Johnson <n3...@mac.com> wrote: >>> >>> On May 23, 2011, at 5:47 PM, Robert Xu wrote: >>> >>>> Hi, >>>> >>>> So now that it's clarified that RPMSENSE_MISSINGOK works... (I can >>>> throw out this patch! >>>> https://github.com/devzero2000/RPM/commit/21ee982d1655c3d8528ed4a32e821aec775ebe14) >>>> >>> >>> Yes you shouldn't need that patch with @rpm5.org. >>> >>>> So... now how could I revise these two patches? >>>> https://github.com/devzero2000/RPM/commit/2a1443ea095ab3cb87fb593f459f299365e7919c >>> >>> This patch shouldn't hurt nor help much (its specific to --queryformat). >>> >>> The basic structure of --singleSprintf isn't radically different. Punt >>> this one to me if you want and I'll figger out how/where the patch >>> should be merged. At a first approximation you can likely run >>> without the patch (but that's just a guess based on where --qf >>> tends to be used). >> >> I will assume for now that this isn't needed. When it comes to actual >> testing, we'll see. >> > > You won't be able to display "strong" and "weak" dependencies without this > patch. So if the following patch is gonna be useful, this patch is gonna > be needed too.
Ah. Then add it to --vendor=suse too then... > >>> >>> >>>> https://github.com/devzero2000/RPM/commit/225db4c7033e014f826fc50ab997f596882c3312 >>> >>> This patch is needed if you want to build packages like SuSE >>> does, with "weak dependencies" in explicit tag data. I can carry >>> this @rpm5.org under >>> #ifdef RPM_VENDOR_OPENSUSE >>> if there is interest. >> >> Please do. :) >> > > todo++. Might be a week or so while I get strapped in on SLES 11.4 ... > > Note that very few packages need/use Suggests: et al. So most builds > will Just Work, and don't need "weak dependencies". Actually, there's been a lot of Recommends/Suggests/PreReq in SuSE spec files lately, so most builds might actually not work. *sigh* they still use PreReq... > > Well there _IS_ a need, just a litter of Suggests: et al hints isn't > the best approach imho. > > The real problem is "preference" and that MUST be general, not > just a handful of usage case semantics tied to some hints like Suggests:. > > Part of "preference" is attaching some metric so that choices can be ordered. > The hard problem is coming up with a "preferences" metric both positive and > negative > that works. I hope Bretzn/AppStream can come up with something... Maybe if they could wire PackageKit through zypp to put these attrs. to better use... > > GeoIP used to sort multiple mirrors by "fastest" is a useful metric. > > The "preference" equivalent is "best" or "worst" (and their weaker forms > "better" and "worse" > and there's no obviously objective way to score that. Yes there are > approaches, > I tend to favor statistical approaches like "voting" (but there are issues > there too > with malicious tampering with the voting results). > > There's a number of approaches, but asking a vendor or a packager > Is this package "good"? > isn't the right approach (and that is built into Suggests: et al). End users > have > preferences, not vendors/packagers. Locales (one of Klaus's examples) have > this problem: > There's like 300+ locales but no person speaks/reads that many > languages. > The metric there is (my guess) matching LC_ALL or some other list of locales > where a subset of all possible locales are then marked with an improved score > as being > "preferred". Too many tags! AHH! > > 73 de Jeff -- later, Robert Xu ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
