RPM Community Forums

Mailing List Message of <rpm-devel>

Re: distepoch problem with latest snapshot of 5.2

From: Matthew Dawkins <mattydaw@gmail.com>
Date: Tue 25 Jan 2011 - 19:42:47 CET
Message-ID: <AANLkTim++SFveec8CdHJptTToAOO0xvhtrg0DcdURk+V@mail.gmail.com>
On Tue, Jan 25, 2011 at 11:14 AM, Jeff Johnson <n3npq@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.


> 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.


> > 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


> 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.


> 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,

Regards,
Matt


> 73 de Jeff
>
>
> > Cheers,
> > Matt
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org
>
Received on Tue Jan 25 19:43:03 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.