This is a multi-part message in MIME format. --------------050802000703050701070303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Well i was refering to compatibility with things like up2date, rpm dist included tools, etc.. Would seem like a waste of time and effort to go out and convince the world to change their standards because 'we want them to' Also gzip might be nice for network transfer time, but for local processing it only adds overhead plus it would rule out future posibilities of janking a header straight out from a regular rpm file, instead of having .hdr files for local repositories. All in all, i see a lot off disadvantages for choosing to go gzip compressed files _only_ and abandoning standards, interoperability, etc. Sure, it's posible to zcat, but _why_ ? R P Herrold wrote: >On Tue, 24 Jun 2003, Chris Chabot wrote: > > > >>Both would rely on non compressed .hdr parsing ;-) >> >> > >Can't the tool just pipe its stream through a gunzip as part >of its parse process? zcat and so forth will leave >non-compressed streams alone and 'do the right thing' when the >magic is not right, as I recall. > >-- Russ Herrold > >_______________________________________________ >Yum mailing list >Yum@xxxxxxxxxxxxxxxxxxxx >https://lists.dulug.duke.edu/mailman/listinfo/yum > > --------------050802000703050701070303 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">Well i was refering to compatibility with things like up2date, rpm dist included tools, etc.. Would seem like a waste of time and effort to go out and convince the world to change their standards because 'we want them to'<br> <br> Also gzip might be nice for network transfer time, but for local processing it only adds overhead plus it would rule out future posibilities of janking a header straight out from a regular rpm file, instead of having .hdr files for local repositories.<br> <br> All in all, i see a lot off disadvantages for choosing to go gzip compressed files _only_ and abandoning standards, interoperability, etc.<br> <br> Sure, it's posible to zcat, but _why_ ?<br> </font><br> R P Herrold wrote:<br> <blockquote type="cite" cite="midPine.LNX.4.44.0306240945100.8399-100000@xxxxxxxxxxxxxxxxxxxxx"> <pre wrap="">On Tue, 24 Jun 2003, Chris Chabot wrote: </pre> <blockquote type="cite"> <pre wrap="">Both would rely on non compressed .hdr parsing ;-) </pre> </blockquote> <pre wrap=""><!----> Can't the tool just pipe its stream through a gunzip as part of its parse process? zcat and so forth will leave non-compressed streams alone and 'do the right thing' when the magic is not right, as I recall. -- Russ Herrold _______________________________________________ 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> --------------050802000703050701070303--
