RPM Community Forums

Mailing List Message of <rpm-users>

Re: rpm-5.0.0 and ftp / http support

From: Jeffrey Johnson <n3npq@me.com>
Date: Sat 10 Dec 2011 - 20:51:45 CET
Message-id: <C8A5B665-D31F-45E8-A7BD-6739C2447E34@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
Received on Sat Dec 10 20:51:49 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.