This is a multi-part message in MIME format. --------------040806080906070301090303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thing is, i'm working on a few other posible patches for yum.. two of which would depend on non-compressed headers. One is a proof-of-concept tool that downloads the headers from a normal redhat ftp server (open rpm file, only read in & parse sig, lead and header part of the file, and save header to disk and generate a local header.info), and one to parse up2date saved headers. Both would rely on non compressed .hdr parsing ;-) seth vidal wrote: >On Tue, 2003-06-24 at 08:05, Chris Chabot wrote: > > >>It seems you haven't used non-gzip compressed headers for a while .. >>;-) >> >>Also, i saw the comments about making non compressed headers >>obsolete.. I would strongly urge you not to. up2date and a lot of >>other tools use the same header format, with the same file extention.. >>It would be a shame to make them non exchangable by forcing & only >>supporting gzip compressed headers. While it's a cool gimic and saves >>some download time, there's no benifit in breaking file compatibility >> >> >> > >Thanks for the patch. You're right. I've not used un-compressed headers >in a while. I bet most other people haven't either. > >-sv > > >_______________________________________________ >Yum mailing list >Yum@xxxxxxxxxxxxxxxxxxxx >https://lists.dulug.duke.edu/mailman/listinfo/yum > > --------------040806080906070301090303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> <font face="Verdana">Thing is, i'm working on a few other posible patches for yum.. two of which would depend on non-compressed headers.<br> <br> One is a proof-of-concept tool that downloads the headers from a normal redhat ftp server (open rpm file, only read in & parse sig, lead and header part of the file, and save header to disk and generate a local header.info), and one to parse up2date saved headers.<br> <br> Both would rely on non compressed .hdr parsing ;-)<br> </font><br> seth vidal wrote:<br> <blockquote type="cite" cite="mid1056456659.24470.4.camel@binkley"> <pre wrap="">On Tue, 2003-06-24 at 08:05, Chris Chabot wrote: </pre> <blockquote type="cite"> <pre wrap="">It seems you haven't used non-gzip compressed headers for a while .. ;-) Also, i saw the comments about making non compressed headers obsolete.. I would strongly urge you not to. up2date and a lot of other tools use the same header format, with the same file extention.. It would be a shame to make them non exchangable by forcing & only supporting gzip compressed headers. While it's a cool gimic and saves some download time, there's no benifit in breaking file compatibility </pre> </blockquote> <pre wrap=""><!----> Thanks for the patch. You're right. I've not used un-compressed headers in a while. I bet most other people haven't either. -sv _______________________________________________ Yum mailing list <a class="moz-txt-link-abbreviated" href="mailto:Yum@xxxxxxxxxxxxxxxxxxxx";>Yum@xxxxxxxxxxxxxxxxxxxx</a> <a class="moz-txt-link-freetext" href="https://lists.dulug.duke.edu/mailman/listinfo/yum";>https://lists.dulug.duke.edu/mailman/listinfo/yum</a> </pre> </blockquote> </body> </html> --------------040806080906070301090303--
