[Yum-devel] Re: [yum-cvs] yum/yum depsolve.py, 1.115, 1.116 packages.py, 1.90, 1.91
Panu Matilainen
pmatilai at laiskiainen.org
Thu Feb 15 07:26:10 UTC 2007
On Thu, 15 Feb 2007, seth vidal wrote:
> On Thu, 2007-02-15 at 09:02 +0200, Panu Matilainen wrote:
>> On Wed, 14 Feb 2007, Jeremy Katz wrote:
>>
>>> On Wed, 2007-02-14 at 20:22 -0500, James Bowes wrote:
>>>> seth vidal wrote:
>>>>> not sure I agree that it is 'being smarter' but sure, we can do that.
>>>>
>>>> I don't care which one is used, but I hope that we can start moving
>>>> towards not sticking the header byte range stuff in primary, and never
>>>> downloading just the headers.
>>>
>>> Not including the header byte ranges breaks the format, so we probably
>>> have to leave it there[1] but that doesn't mean that yum has to care
>>> about them or ever download them
>>
>> AFAIK yum is the only depsolver that ever used the header ranges for
>> anything. At least smart and apt-rpm don't use them at all, never have.
>>
>> P.S. This should really be discussed on the metadata list, not here :)
>
> We're not going to remove anything from the format for the sake of not
> having to worry about any of the parsers breaking. If there is data not
> being used it can just be ignored.
>
> and until I have the energy to go through the process w/the metadata
> list of changing the xml format. I think we should probably hold off.
I wasn't exactly suggesting removing those fields right now, just
commenting on their usage. A couple of numeric values less or more doesn't
make any noticeable difference to the metadata size so it's pretty
irrelevant.
What I would like to see however is an open discussion for "repodata 2.0"
format on the metadata list. By now people have lots of field experience
with "version 1.0", what's good and what's less than optimal there, and
probably various suggestions how it could/should be improved. Oh and
obviously anybody (me included) could start the discussion there as well,
I'm not pointing fingers here :)
- Panu -
More information about the Yum-devel
mailing list