headers
Christoph Thiel | 8 May 2006 12:38
Picon
Gravatar

Re: Zero epoch vs no epoch (patch)

On Sat, 29 Apr 2006, Panu Matilainen wrote:

> > > > >  - Even if no epoch is specified, the metadata still specifies 
> > > > >    this as "0".  For most code paths this is no problem as for 
> > > > >    all comparisons of version data, a missing epoch is the same 
> > > > >    as a "0"  epoch. This should not be a huge problem and would 
> > > > >    be only a cleanup item for the repodata.
> > > >
> > > > what does removing 0-epoch items buy us?
> > >
> > > What it buys is support for ancient rpm versions. Remember those 
> > > monstrosities where non-existing epoch is not equal to zero epoch, 
> > > epoch promotion and all that fun? I couldn't personally care less 
> > > about the old rpm versions but there are people who do care, for 
> > > example Dag and Matthias: 
> > > http://lists.freshrpms.net/pipermail/freshrpms-list/2006-April/014022.html
> > >
> > > Removing those zero epochs from repodata makes yum rather unhappy, 
> > > dunno about smart, so changing the default is not really a 
> > > possibility. But then neither supports the prehistoric versions that 
> > > are of concern here. Attached quick hack of a patch adds a switch to 
> > > turn off adding those artificial zero epochs, using this as 
> > > necessary this should be enough to allow using repodata with full 
> > > rpm 3.0.x - 4.4.x range.
> >
> > When we were implementing rpm-md support for our online update 
> > channels, we stumbled over the epoch thingy as well, but had to add 
> > the epoch="0", to keep yum & smart intact. The funny thing we found 
> > was the fact that rpm itself doesn't handel an empty epoch 
> > consistently -- if there is any interest, I'll dig into the rpm code
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeff Johnson | 8 May 2006 13:31

Re: Zero epoch vs no epoch (patch)


On May 8, 2006, at 6:38 AM, Christoph Thiel wrote:

> On Sat, 29 Apr 2006, Panu Matilainen wrote:
>
>>>>>>  - Even if no epoch is specified, the metadata still specifies
>>>>>>    this as "0".  For most code paths this is no problem as for
>>>>>>    all comparisons of version data, a missing epoch is the same
>>>>>>    as a "0"  epoch. This should not be a huge problem and would
>>>>>>    be only a cleanup item for the repodata.
>>>>>
>>>>> what does removing 0-epoch items buy us?
>>>>
>>>> What it buys is support for ancient rpm versions. Remember those
>>>> monstrosities where non-existing epoch is not equal to zero epoch,
>>>> epoch promotion and all that fun? I couldn't personally care less
>>>> about the old rpm versions but there are people who do care, for
>>>> example Dag and Matthias:
>>>> http://lists.freshrpms.net/pipermail/freshrpms-list/2006-April/ 
>>>> 014022.html
>>>>
>>>> Removing those zero epochs from repodata makes yum rather unhappy,
>>>> dunno about smart, so changing the default is not really a
>>>> possibility. But then neither supports the prehistoric versions  
>>>> that
>>>> are of concern here. Attached quick hack of a patch adds a  
>>>> switch to
>>>> turn off adding those artificial zero epochs, using this as
>>>> necessary this should be enough to allow using repodata with full
>>>> rpm 3.0.x - 4.4.x range.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christoph Thiel | 8 May 2006 15:51
Picon
Gravatar

Re: Zero epoch vs no epoch (patch)

On Mon, 8 May 2006, Jeff Johnson wrote:

> >I just went through the code of rpm 4.4.5 with our RPM maintainer again 
> >and we found:
> >
> >rpmVersionCompare (psm.c):
> >=> no epoch is smaller than epoch 0
> >
> 
> rpmVersionCompare is old (and broken).
> 
> There are two uses in rpmlib, both tainted with legacy.
> 
> One use case is --freshen, which is left exactly as it always has been.
> 
> The other use is determining "identical" headers where the header SHA1 is
> compared before EVR, and the SHA1 comparison invariably determines whether
> 2 headers are exactly identical no mater what EVR is present.
> 
> >rpmdsCompare(rpmds.c)
> >=> no epoch is equal to epoch 0
> >
> 
> rpmdsCompare is the current paradigm, missing epoch is exactly 0, used
> everywhere consistently,
> and its behavior is described as
>     Missing or non-specified epoch is treated exactly as Epoch: 0 is.
> 
> So what's your issue? Presumably with something other than rpm itself.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Panu Matilainen | 17 May 2006 20:33

Re: Zero epoch vs no epoch (patch)

On Sun, 30 Apr 2006, seth vidal wrote:

> On Sat, 2006-04-29 at 22:13 -0700, Panu Matilainen wrote:
>>>
>>> Why do you need this? What system isn't using a modern version of rpm?
>>
>> I don't need it, users do. For example RHEL 2.1 has rpm 4.0.x and it's
>> supported until May 2009, and RHL 9 and derivates (which is also affected
>> by this) even if long since unsupported is popular still. Not to mention
>> various non-RH distros, various Suse enterprise products as I understand
>> it etc.
>>
>> There are good reasons people would like to get rid of the old apt
>> metadata format:
>> - it has artificial limitations on directory structure
>> - yet another data format to deal with + tools to run it
>
> Understood. I just had to ask what the goal was for this patch - who it
> was impacting.
>
> Do you think you could add another caveat into --help that mentions why
> one would or would not use -n?
>
> then I'll go ahead and merge the patch.

Is this acceptable explanation for the option?

On a side note, createrepo could use converting to OptionParser :) Oh 
well, a project for another day perhaps.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Aawardhan Logandhan | 31 May 2006 11:25
Picon

Compatibility between yum (version 2.0.6) with the latest !!

Hi,
 
Consider a situation in which there is a RPM repository which stores all the latest RPMs. And there are, say, 100 target machine in the network, which has to be updated with the latest versions from the RPM repository. But these target machine may not have the latest versions of YUM.
 
Now the new YUM tool will not support the repository generated by yum-arch. Which format of the meta-data to maintian in the RPM repository.
 
Can I run both yum-arch and create-repo.. so that the RPM repository has both the old and new format of the header files(meta-data).. now if the target machine has new version of YUM.. it will look for the XML format meta data.. while the target machines with old version of YUM will look for the header.info file..
 
Is this true??? If not suggest me, how to solve the problem???
 
_______________________________________________
Rpm-metadata mailing list
Rpm-metadata <at> lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-metadata
Permalink | Reply | 1 comment |
headers
Jos Vos | 31 May 2006 11:30
Picon

Re: Compatibility between yum (version 2.0.6) with the latest !!

On Wed, May 31, 2006 at 02:55:36PM +0530, Aawardhan Logandhan wrote:

> Can I run both yum-arch and create-repo.. so that the RPM repository has
> both the old and new format of the header files(meta-data).. now if the

Both repo formats can perfectly be combined, I'm doing that since years
(even together with an apt repository) for our X/OS Linux distro, where
yum is using the new repo and up2date still accesses the old repo.

--

-- 
--    Jos Vos <jos <at> xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204
Permalink | Reply | 0 comments |

Gmane