Re: distepoch problem with latest snapshot of 5.2
Matthew Dawkins wrote:
I recently updated my snapshot of 5.2 to build around a perl upgrade to
5.12.2, but I didn't expect any problems really.
Well pkgs that have requires like the following:
Provides: libpq = %{version}-%{release}
now also have this half distepoch after it :2011.1
made with a newer rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.5-3-
unity2011.0.x86_64.rpm
postgresql-libs = 8.4.5-3
libpq = 8.4.5-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
lib64pq8.4_5 = 8.4.5-3:2011.0
made with the older rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.4-3-unity2010.x86_64.rpm
postgresql-libs = 8.4.4-3
libpq = 8.4.4-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
lib64pq8.4_5 = 8.4.4-3
This output looks different from what is initially described...
i.e. the Provides: libpq = %{version}-%{release} are the same,
or at least not having a distepoch appended to the version-release
The difference is instead the implicit provides (lib64pq8.4_5)
Unity != Mandriva
The problem for Unity was that smart doesn't support it, nor does createrepo
(i'm guessing)
Originally there was one problem with rpm version display (in smart),
which expanded into one markup issue with createrepo (and thus yum):
The rpm versions were showing up without the -%{disttag}%{distepoch}.
Adding that (where present) to the RPM Loader, made the packages not
match the ones in the Metadata Loader - and each would show up twice.
Thus a createrepo patch was made to add rpm:disttag/rpm:distepoch.
For the issue above, smart would also need to append a :%{distepoch}
suffix to the version of the NameProvides created for each package.
There was also a (minor) issue about distepochs not being properly
split from version, so that they would end up in R rather than in D.
I don't think either issue is tracked at https://launchpad.net/smart
But all code is done, possibly lacking some on/off opt-out config...
Don't really see any rpm issues here, other than adding more ways
to have it your own way and I still don't know what the distepoch
is useful for since I'm not using it myself (wrong vendor/packages).
So problems are similar to the other ones with suggests/recommends.
Or well I know what %{?dist} and %mkrel are being used for, and how
Distepoch cleans up the Release field. I just don't know how useful
it is to be able to compare package versions between OS releases ?
Or if any gain outweighs the loss of the incompatibility introduced.
--anders
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: distepoch problem with latest snapshot of 5.2
On Jan 26, 2011, at 4:15 AM, Anders F Björklund wrote:
Matthew Dawkins wrote:
I recently updated my snapshot of 5.2 to build around a perl upgrade to
5.12.2, but I didn't expect any problems really.
Well pkgs that have requires like the following:
Provides: libpq = %{version}-%{release}
now also have this half distepoch after it :2011.1
made with a newer rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.5-3-
unity2011.0.x86_64.rpm
postgresql-libs = 8.4.5-3
libpq = 8.4.5-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
lib64pq8.4_5 = 8.4.5-3:2011.0
made with the older rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.4-3-unity2010.x86_64.rpm
postgresql-libs = 8.4.4-3
libpq = 8.4.4-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
lib64pq8.4_5 = 8.4.4-3
This output looks different from what is initially described...
i.e. the Provides: libpq = %{version}-%{release} are the same,
or at least not having a distepoch appended to the version-release
The difference is instead the implicit provides (lib64pq8.4_5)
Unity != Mandriva
The problem for Unity was that smart doesn't support it, nor does createrepo
(i'm guessing)
Originally there was one problem with rpm version display (in smart),
which expanded into one markup issue with createrepo (and thus yum):
The rpm versions were showing up without the -%{disttag}%{distepoch}.
Adding that (where present) to the RPM Loader, made the packages not
match the ones in the Metadata Loader - and each would show up twice.
Thus a createrepo patch was made to add rpm:disttag/rpm:distepoch.
For the issue above, smart would also need to append a :%{distepoch}
suffix to the version of the NameProvides created for each package.
There was also a (minor) issue about distepochs not being properly
split from version, so that they would end up in R rather than in D.
Pretty soon now, there needs to be a choice between :foo and -foo
to separate added fields. Otherwise we're all doomed to stare at spewage
for the next couple of years.
I personally believe that '-' is the better choice because its
already a forbidden character used for splitting EVR dependency tuples,
and is already de facto imposed by %mkrel appending Distag: and Distepoch:
to RPMTAG_RELEASE.
There plain and simply is no justficiation for Yet More Aesthetic Spewage Markup
that I will ever understand.
Meanwhile SOME convention for disttag/distepoch patrsing is better than
Have it your own way!
well duh!.
I don't think either issue is tracked at https://launchpad.net/smart
But all code is done, possibly lacking some on/off opt-out config...
Good.
Don't really see any rpm issues here, other than adding more ways
to have it your own way and I still don't know what the distepoch
is useful for since I'm not using it myself (wrong vendor/packages).
So problems are similar to the other ones with suggests/recommends.
Distepich: is no better or worse than any other identification/branding scheme.
But %mkrel implemented as a parameterized macro with its 3-4 layers
of nested macros is too fragile/feeble a form of macro madness imho.
And a specific tag in metadata, with a known semantic, and explictly
enumerable values, is sounder engineering than appending more clutter
to Release: fields. Note that you can append to RPMTAG_RELEASE with
whatever semiotic markers you wish for whatever purpose you want to
be parsed by whatever tools you choose forevermore. That is indeed
Have it your own way!
in action.
Or well I know what %{?dist} and %mkrel are being used for, and how
Distepoch cleans up the Release field. I just don't know how useful
it is to be able to compare package versions between OS releases ?
Or if any gain outweighs the loss of the incompatibility introduced.
If done correctly and carefully, there is _NO_ incompatibility introduced
by Distepoch: or by Distag: or Repotag: or ... appended to Release: strings.
strings == strings
Everything else intended for identification/branding purposes has nothing
to do with Distepoch: or %{?distag} or ...
Thanks for comments. You are still as sane as ever ;-)
73 de Jeff__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: distepoch problem with latest snapshot of 5.2
On Fri, Jan 14, 2011 at 11:05 AM, Matthew Dawkins matty...@gmail.comwrote:
I recently updated my snapshot of 5.2 to build around a perl upgrade to
5.12.2, but I didn't expect any problems really.
Well pkgs that have requires like the following:
Provides: libpq = %{version}-%{release}
now also have this half distepoch after it :2011.1
made with a newer rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.5-3-
unity2011.0.x86_64.rpm
postgresql-libs = 8.4.5-3
libpq = 8.4.5-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
*lib64pq8.4_5 = 8.4.5-3:2011.0*
made with the older rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.4-3-unity2010.x86_64.rpm
postgresql-libs = 8.4.4-3
libpq = 8.4.4-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
*lib64pq8.4_5 = 8.4.4-3*
Funny how I get no responses on this problem. It looks pretty familiar
to what's being reported on cooker hmmm
Tia
Re: distepoch problem with latest snapshot of 5.2
On Jan 25, 2011, at 12:08 PM, Matthew Dawkins wrote:
On Fri, Jan 14, 2011 at 11:05 AM, Matthew Dawkins matty...@gmail.com wrote:
I recently updated my snapshot of 5.2 to build around a perl upgrade to
5.12.2, but I didn't expect any problems really.
Well pkgs that have requires like the following:
Provides: libpq = %{version}-%{release}
now also have this half distepoch after it :2011.1
made with a newer rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.5-3-
unity2011.0.x86_64.rpm
postgresql-libs = 8.4.5-3
libpq = 8.4.5-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
lib64pq8.4_5 = 8.4.5-3:2011.0
made with the older rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.4-3-unity2010.x86_64.rpm
postgresql-libs = 8.4.4-3
libpq = 8.4.4-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
lib64pq8.4_5 = 8.4.4-3
Funny how I get no responses on this problem. It looks pretty familiar to
what's being reported on cooker hmmm
Well have a response for free ;-)
What I cannot do is solve a legacy compatibility issue because rpm-4.6.1 just
ain't
my problem mon. Similarly, I cannot dictate what solution is appropriate for
Mandriva
and Unity.
73 de Jeff
Re: distepoch problem with latest snapshot of 5.2
On Tue, Jan 25, 2011 at 10:18 AM, Jeff Johnson n3...@mac.com wrote:
On Jan 25, 2011, at 12:08 PM, Matthew Dawkins wrote:
On Fri, Jan 14, 2011 at 11:05 AM, Matthew Dawkins matty...@gmail.comwrote:
I recently updated my snapshot of 5.2 to build around a perl upgrade to
5.12.2, but I didn't expect any problems really.
Well pkgs that have requires like the following:
Provides: libpq = %{version}-%{release}
now also have this half distepoch after it :2011.1
made with a newer rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.5-3-
unity2011.0.x86_64.rpm
postgresql-libs = 8.4.5-3
libpq = 8.4.5-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
*lib64pq8.4_5 = 8.4.5-3:2011.0*
made with the older rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.4-3-unity2010.x86_64.rpm
postgresql-libs = 8.4.4-3
libpq = 8.4.4-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
*lib64pq8.4_5 = 8.4.4-3*
Funny how I get no responses on this problem. It looks pretty familiar
to what's being reported on cooker hmmm
Well have a response for free ;-)
What I cannot do is solve a legacy compatibility issue because rpm-4.6.1
just ain't
my problem mon. Similarly, I cannot dictate what solution is appropriate
for Mandriva
and Unity.
73 de Jeff
Unity != Mandriva
The problem for Unity was that smart doesn't support it, nor does createrepo
(i'm guessing)
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!
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
Cheers,
Matt
Re: distepoch problem with latest snapshot of 5.2
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. 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. 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. 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. 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. 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. 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. 73 de Jeff Cheers, Matt __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: distepoch problem with latest snapshot of 5.2
2011/1/25 Matthew Dawkins matty...@gmail.com:
On Fri, Jan 14, 2011 at 11:05 AM, Matthew Dawkins matty...@gmail.com
wrote:
I recently updated my snapshot of 5.2 to build around a perl upgrade to
5.12.2, but I didn't expect any problems really.
Well pkgs that have requires like the following:
Provides: libpq = %{version}-%{release}
now also have this half distepoch after it :2011.1
made with a newer rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.5-3-
unity2011.0.x86_64.rpm
postgresql-libs = 8.4.5-3
libpq = 8.4.5-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
lib64pq8.4_5 = 8.4.5-3:2011.0
made with the older rpm5.2 snapshot
rpm -qp --provides lib64pq8.4_5-8.4.4-3-unity2010.x86_64.rpm
postgresql-libs = 8.4.4-3
libpq = 8.4.4-3
lib64pq8.4_5-virtual = 8.4
libpq.so.5()(64bit)
lib64pq8.4_5 = 8.4.4-3
Funny how I get no responses on this problem. It looks pretty familiar
to what's being reported on cooker hmmm
I've been occupied with getting the situation for cooker stabilized
and most crucially, getting
our buildsystem up and running without new issues.
With horrible spaghetti perl code in urpmi, various versions of both
rpm and URPM used on hosts
generrating metadata, mess of my own and general stress making the
situation more painful,
I'm only now starting to get there..
Meanwhile there's nothing preventing you from fixing this yourself
(I've already told you where and what
needs fixing), nor anything forcing you to switch to rpm 5.3 (in
contrast to cooker where I've already forced the change upon
everyone,making my priorities rather obvious).
I'll try get smart fixed over the next days..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: distepoch problem with latest snapshot of 5.2
On Jan 25, 2011, at 1:23 PM, Per Øyvind Karlsen wrote: Funny how I get no responses on this problem. It looks pretty familiar to what's being reported on cooker hmmm I've been occupied with getting the situation for cooker stabilized and most crucially, getting our buildsystem up and running without new issues. All of which is qute a cruel a bruising logistical task (been there, done that, many times). You're doing fine even if I disagree with your check-in's at times. E.g I'm quite happy to see LOOP: messages exposed even if I privately wince at the support issues that will inevitably follow if the output is just inflicted on lusers (the better answer is to pro-actively nuke as many of the LOOP's as possible to achieve the watershed where its easier to fix the few remaining issues than it is to yell Geronimo! and wait several more years to fix anything). There's most definitely triage and hacks and plateaus and more that can be done to achive forward progress. With horrible spaghetti perl code in urpmi, various versions of both rpm and URPM used on hosts generrating metadata, mess of my own and general stress making the situation more painful, I'm only now starting to get there.. Yep. And -- just judging from the rising incidence of complaints -- you making good forward progress. Its always most painful just before you succeed. Meanwhile there's nothing preventing you from fixing this yourself (I've already told you where and what needs fixing), nor anything forcing you to switch to rpm 5.3 (in contrast to cooker where I've already forced the change upon everyone,making my priorities rather obvious). I'll try get smart fixed over the next days.. What is the issue in smart? Is it just a mis-matched Provides: - Requires: dependent on whether :2010.1 is appended 2 place or none? 73 de Jeff -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: distepoch problem with latest snapshot of 5.2
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. 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 Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: distepoch problem with latest snapshot of 5.2
2011/1/25 Jeff Johnson n3...@mac.com: 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. 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. I should fairly easily be able to dig out and clean up the conversion code from URPM.xs to either fit in a independent tool or as a python module using python's C api to integrate with smart... But I just need to make my way there first, I can only scale so-so much at a time.. Is that sufficient assurance or not? -- Regards, Per Øyvind __ RPM Package Manager
Re: distepoch problem with latest snapshot of 5.2
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.
Re: distepoch problem with latest snapshot of 5.2
On Jan 25, 2011, at 3:09 PM, Matthew Dawkins wrote: Yes, I have been following Per's work at Mandriva and I have been waiting for the right time to go for this. Ready when you are. I think all the pieces are in place. But don't take my word as assurance, ask Nigel or anyone on Coooker and make up your own mind. But I can/will schedule some time to assist with a UL upgrade to RPM ACID. That is in fact what I've been doing for the last 2 months with Mandriva, just progress is a bit more complex there becuase of other issues related to port's and URPMI an iurt and rpmdrake and ... Getting UL + smart functional SHOULD be easy-pie. 73 de Jeff
