RPM Community Forums

Mailing List Message of <rpm-users>

Re: rpm-5.0.0 and ftp / http support

From: devzero2000 <pinto.elia@gmail.com>
Date: Sun 11 Dec 2011 - 00:02:54 CET
Message-ID: <CAH5b-BVJ4myHBbqX5M2g773fD0PUbSiAT2qA6rUFzOPdD_t-Ag@mail.gmail.com>
Yes, make sense.

Best regards

2011/12/10, Jeffrey Johnson <n3npq@me.com>:
> 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                             rpm-users@rpm5.org

Inviato dal mio dispositivo mobile
Received on Sun Dec 11 00:02:59 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.