[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Summary: protocol support in rpm is a Good Thing



On Sun, Feb 18, 2001 at 09:10:44AM -0500, Jeff Johnson wrote:
> On Sat, Feb 17, 2001 at 11:31:52PM -0300, Rodrigo Barbosa (aka morcego) wrote:
> > On Sat, Feb 17, 2001 at 02:21:34PM -0500, Jeff Johnson wrote:
> > > After re-reading recent messages on rpm-list, I believe that I have
> > > an answer to my question
> > > 
> > > 	Should rpm have support for *any* protocols at all?
> > > 
> > > The answer, AFAICT, is YES with the following (possible) reservations:
> > 
> > I don't like the idea, but I see the need (old discussion).
> > 
> > > 1) Protocol support should be "clean", "modular", "flexible", "extensible".
> > 
> > agreed
> > 
> > > So let's move this discussion on to design and implementation of protocol
> > > support in rpm:
> > > 
> > > 	0) Is the freshen.sh popt magic extension well enough understood
> > > 	and satisfactory for those who wish to implement protocol support
> > > 	(and, implictly, dependency solvers) outside of rpm, but yet still
> > > 	use their implementation to be accessed from an rpm command line?
> > 
> > No.:-)
> 
> Details, please. There's a class of people who wish to have a solution
> to package download policies (and eventually dependency solvers) that does not
> involve rpm at all, and the popt magic extension, basically a command line
> argument filter that re-execs rpm with (possibly different) arguments
> certainly seems to have all of the properties "clean", "modular", "flexible"
> and "extensible", with the added bonus that I don't have to change a
> single line of code in rpm (Thank you Erik!).

lol ... The point is, it's too messy and a confusion. I tried to use/understand
it once, and quite trying not long after :-)

> > > 	1) Is the support for FTP/HTTP in rpmio viable? FTP, in particular,
> > > 	has a rich and checkered (but well known) legacy, and the HTTP support
> > > 	in rpmio is modest (no server redirects, etc).
> > 
> > Viable, yes.
> 
> Good.

Lemme say it again: Viable. Not easy or (necessarily) worth the effort.

> > > 	2) What other protocols should be supported? Remember, I'm expecting
> > > 	to need to support some sort of xdelta/rsync protocol Real Soon Now,
> > > 	and I don't know any other way of doing that (at the moment) except
> > > 	by implementing the protocol directly in rpm. The rationale is that
> > > 	it's just too hard to rip off all the digital signature, compression,
> > > 	and payload layers to get at the bits that need to be deltafied
> > > 	from outside rpm without a very, very complicated API. Personally, I'd
> > > 	rather just slam dunk an xdelta/rsync clone directly in rpm.
> > > 
> > > 	LDAP? NFS? SSH? XML-RPC? RPC? RDIST? RCP?
> > > 	Name your poison, I can sing that tune :-)
> > 
> > You have that Proof Of Concept I sent you based on XML-RPC ...
> > 
> 
> Yup, but I still need consensus on whether XML-RPC as an rpm internal protocol
> is the right thing to do. Adding an rpm build dependency on, say, expat or
> libxml, will be painful, rolling an internal XML parser from scratch is not
> hard, but not trivial either. Distinguishing the "representation" in XML from
> other data attributes like "access method" is gonna be confusing, since an XML
> enabled application usually can import existing functionality at will,
> that won't always work for rpm, which must be able to easily run in empty
> chroot's.
> 
> For another example of why "representation" in XML is slippery, I see little
> reason why XML should be used to represent metadata saved in the rpm database,
> that just pushes an XML parse onto every header access in rpm, leading to slower
> installs and more complicated accesses, for no detectable gain in existing
> rpm functionality.

Well, we can just use HTTP and some wierd mime-type, and be done with it.

> > > 	I do point out that rpm should try as best as possible to remain a
> > > 	"pure" client on an existing protocol implementation, I'm not yet
> > > 	convinced that the time has come to write a "custom" protocol
> > > 	implemented in, for example, /usr/sbin/rpmd, there's far too many
> > > 	non-package management issues opened by that approach.
> > 
> > I'm sorry to say, but rpm enabled apt is around.
> > 
> 
> >>From the rpm command line? I'll be happy to add the support to rpm. Remember,
> I'm looking for a dependency solver that works from the rpm command line,
> not a dependency solver that understands rpm packaging, that's
> 	The Problem Of Apt
> that I'm trying to solve :-)

Big trouble :-)

> > > 	3) How should the protocols be used by rpm? I already know (but you may
> > > 	not) that I need to be able to access an "index" remotely in order
> > > 	to implement a dependency solver, I currently plan to use some
> > > 	protocol to get at a remote rpm database.
> > 
> > XML-RPC ... We all know the reason (firewalls).
> > 
> 
> What Rodrigo is referring to is the sad reality that often only HTTP is
> permitted through firewalls, that almost dictates that HTTP must be used
> as a transport protocol for anything and everything. Other protocols like
> XML-RPC can be layered on top of HTTP, however, and there are other protocols
> often permitted through firewalls, SSH comes to mind.

No to mine. Most fw I've seen doesn't allow SSH, or allow it only to
fixed, preconfigured hosts. Not a good idea.

> > > 	4) Where should URL's be permitted within rpm? Not having a mandate
> > > 	for protocol suppport and without any reason to do otherwise, my
> > > 	current answer is
> > > 		Everywhere that a file path can be used in rpm.
> > > 	although I can easily be persuaded of the Insanity of This Approach.
> > > 
> > > 	FWIW, you might try using "file://" like URL's within the current
> > > 	rpmio implementation to convince yourself that, indeed, I've
> > > 	managed to drill URL support quite deeply (and quietly :-) into
> > > 	rpm already.
> > > 
> > > Opinions (and coders :-) welcomed.
> > 
> > Jeff,
> > 	if you want my humble opinion, what you need it libapt :-)
> > 
> 
> I'll be happy to add libapt if there's consensus that libapt is the
> right thing to do.

And who need to agree ? If anyone else besides us coding ? :-)
(Pretend it have not been 4 weeks ago I sent you my last piece of
code:-))

[]s

-- 
 Rodrigo Barbosa (morcego)         - rodrigob at conectiva.com.br
 Conectiva R&D Team                - http://distro.conectiva.com.br
 "Quis custodiet ipsos custodiet?" - http://www.conectiva.com

Attachment: pgp00007.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []