Yes, make sense. Best regards
2011/12/10, Jeffrey Johnson <[email protected]>: > > On Dec 10, 2011, at 2:21 PM, Per Øyvind Karlsen wrote: > > ... >>> >>> I changed the behavior a few years back (I've forgot why, there is/was a >>> reason). >>> > > BTW, I remembered the reason for the change. > > Network transport has always been "opt-in" rather than "opt-out". > I changed from > %_rpmgio %{nil} > to > %_rpmgio ".ufdio" > because it seemed awkwardly arcane to commit to a "opt-in" syntax > specified by setting a switch to %{nil}. > > Meanwhile the end-point is "opt-out" behavior, not "opt-in". Noone > ever bothers configuring RPM unless they have to. So "opt-in" > is equivalent to not implmented at all in most cases (like this thread > shows). > >>> Here's the comment (and tested with first URL at the bug report on >>> mdv2011) >>> I added to bz#64914 >>> >>> If you configure a macro, then ftp/http transport will be re-enabled. >>> >>> This can be done on the CLI by adding >>> -D '_rpmgio .ufdio' >>> of done persistently by doing >>> echo '%_rpmgio .ufdio' >> /etc/rpm/macros >>> >>> Note that this is "unsupported" (by Mandriva) functionality in RPM. >> Well, we're just using the default as defined in /usr/lib/rpm/macros, >> but if there's no >> specific drawbacks I shold be aware of beyond the limitations of this >> support you mention, >> I'd be happy to change the default to enable this in our >> /usr/lib/rpm/macros.d/mandriva.. :) >> > > Well there aren't any specific drawbacks or there would have been > multiple RFE's to enable network transport in mdv2011 already, and > that did not happen, so the usage case is quite small. > > So you likely can re-enable by adding > %_rpmgio .ufdio > somewhere and everyone will continue to not notice > or use RPM network transport in mdv2011. > > A more serious effort to achieve "opt-out" behavior and reliability in RPM > would involve fixing some of the deficiencies. > > The ability to resume from an interrupted download is perhaps the next most > useful > functionality. Its little more than a stat(2) call and (if there is > a partial i.e. use Content-Length: to tell download that exists, seek to > end and add the necessary byte range marker to resume the transfer in the > middle). > > The "No support for HTTP 30x redirects." isn't impossibly hard: the URL > needs to be substituted, and the open restarted. But there's a > lot of trash code and debugging that should be hauled out first. > > The "No support for certs." is deeply complex because a certificate > store would be needed and that's fairly painful to get right and deploy. > > To maintain network transport in RPM, there needs to be a test harness > setup to exercise a reasonable functionality. Anything else will > become wild hacks for obscure corner cases, and I really don't > wish to spend the next few years chasing obscure corner cases in > real time: its just simpler/saner to setup a test harness up front > in order to define "supported" functionality. > > Make sense? > > 73 de > Jeff______________________________________________________________________ > RPM Package Manager http://rpm5.org > User Communication List [email protected] > -- Inviato dal mio dispositivo mobile ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List [email protected]
