On Tue, Jan 25, 2011 at 12:06 PM, Jeff Johnson <n3...@mac.com> wrote:
> > On Jan 25, 2011, at 1:42 PM, Matthew Dawkins wrote: > > > > On Tue, Jan 25, 2011 at 11:14 AM, Jeff Johnson <n3...@mac.com> wrote: > >> >> On Jan 25, 2011, at 12:52 PM, Matthew Dawkins wrote: >> >> > >> > Unity != Mandriva >> > >> > The problem for Unity was that smart doesn't support it, nor does >> createrepo (i'm guessing) >> > >> >> There's nothing to support with smart and/or createrepo if Distepoch: is >> finished. >> >> > I'd like to see AFB's comments there, b/c we spoke about it at one point. > > > > Comments are welcomed. But I can't reason from "No comment." to either > "No interest" or "No problem" any better than anyone else. > > Its all just smoke-and-mirrors to get a sounder basis for >> identification/branding, >> and to remove the need for %mkrel being configured during build's. >> >> > I fully support the idea of what distepoch is supposted to be, but maybe > this is a question of more eating our own dog food than anything else? This > problem can't be spotted until rpms are built with rpm5 and the feature > being enabled. > > > > Yes, usage is absolutely crucial. FWIW, I'm quite sure Mandriva would not > be > attempting Distepoch: if UL had not succeeded already. > > > AFAIK we have always disabled it b/c of the said problems and lack of full support upstream in smart and createrepo. > > A courtesy response is nice otherwise it feels like we are just getting >> ignored for the better, more well planned mother project. It seems testing >> and error report checking are a big todo there too! >> > >> >> Because Distepoch: is under >> #ifdef RPM_VENDOR_MANDRIVA >> I can't solve any issues directly. Just like filetriggers. >> >> What I have tried to do is to force the issue into RPM (or back to >> vendor's), >> and have asked for opinions on whether to include Distepoch: and file >> triggers >> directly in RPM or rip it out. >> >> I've heard exactly zero opinions on the vendor specific issues, all of >> which >> have been mapped into launcpad.net/rpm blueprint's for discussion. >> >> > Usually no response means a couple things, don't know, don't care and no > objections. > Sorry for the no response, but there are no objections here. > > >> My personal opinion is still conflicted wrto both Distepoch: and file >> triggers. >> >> But I cannot be blamed for "support" of vendor-peculier changes that I >> never see or use. >> >> > Hmm maybe supporting those that take time to support you is a good > practice. I don't know how you think rpm5 will ever get huge traction if > your default support are for two platforms that will never support you, but > the two biggest platforms that support you aren't even on the menu. > > > > > > I can't think of another project that has used and deployed rpm5 more and >> our experiences are still chucked to the side like rubbish. TY >> > >> >> Rubbish? Chucked? If I'm at fault, please speak plainly and I will try to >> accomodate. >> >> > I emailed you directly first. /me shrugs > > > > If you're talking about the e-mail you sent ~10 days ago, I was contracting > at > a customer site with the flu. All I could do is curl up into a fetal > position evenings/weekends in > order to be ready for the next day's efforts. I was living on OJ and > without > coffee or even solid food for about a week. That's life, or at leas was my > past > 2 week's. I'm still catching up and have to return next Monday. > > > My development focus is on rpm-5.4.x to get out of the way of Mandriva >> adopting rpm-5.3.x. >> >> And my previous devel focus was rpm-5.3.x to give UL a stable rpm-5.2.x. >> >> > The reason we haven't adopted > 5.2.x is b/c we were never assured a > problem free upgrade path to 5.3.x nor were we assured that all the fixes > that we had worked so hard figuring out on 5.2.x were upstreamed. > > > What passes for "assurance"? I've been using rpm-5.3.x for 1.5 years. And > I'm > most definitely _NOT_ going to attempt "compatible" with rpm-5.3.x, the > issues are too big and profound. > > Meanwhile, the "conversion" isn't that hard, and I supplied all of the > details, > as well as running the conversion on the odd 10-15 linux distro boxes under > buildbot's and helped at lengtrh sort out the issue with Per Oyvind's > conversion > script being deployed in main/testing. > > But I CANNOT support seamless drop-in "compatibility" going both forwards > and > backwards between rpm-5.3.7 <-> rpm-4.6.1. That was a deliberate and > conscious > non-goal of "RPM ACID" even though I deliberately made sure that the > conversion > was quite simple and straight forward. > > > >> But that also means that I'm several steps away from fixing anything, and >> haven't >> any basis for a "release" or "fixing" or much else. >> >> > Lil by lil, > > > ARe you interested in upgrading to "RPM ACID"? IDMS has managed that > conversion, > and Mandriva Cooker is there too as well. > > Is that sufficient "assurance" or not? > > 73 de Jeff > Yes, I have been following Per's work at Mandriva and I have been waiting for the right time to go for this.
