[devel] [jbj на JBJ.ORG: Summary: protocol support in rpm is a Good Thing]

[Dmitry V. Levin]

Just FYI: перспективы развития RPM на ближайшее (и не только) будущее.

----- Forwarded message from Jeff Johnson <jbj на JBJ.ORG> -----

Date: Sat, 17 Feb 2001 14:21:34 -0500
From: Jeff Johnson <jbj на JBJ.ORG>
To: rpm-list на redhat.com
Subject: Summary: protocol support in rpm is a Good Thing

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:

1) Protocol support should be "clean", "modular", "flexible", "extensible".

2) Protocol needs are different for different modes within rpm, and/or for
different types of information being retrieved, and so may need to be
"configurable" on a per-mode or per-executable basis.

Apologies if I've mis-stated or mis-understood any comments, feel free
to correct me. And, as always, contrarian view points are welcomed.

Hence, in the future, I will cheerfully respond to questions like
	Why does rpm have support for *any* protocols at all?
with the answer
	Because that's what rpm needs.

And, if you think this process unnecessary in some sense, all I can say is
that I *need* a mandate for protocol support in rpm, however tepid, in order
to justify development and maintainence of the code, a single off-hand comment
like
	Why is rpm doing this anyways, why don't we do <...>?
is the Kiss Of Death to rpm development. There's a reason why rpmio is not well
documented, think a bit :-)

(Aside: This entire process is otherwise known as "Consensus Building" :-)

I have several development goals in mind, all basically subsumed under the term
	The Problem Of Apt
i.e. how to provide transitive closure to a set of dependencies so that
an upgrade, even from the rpm command line, is *easy*.

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?

	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).

	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 :-)
	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.

	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.

	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.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj на jbj.org	(jbj на redhat.com)
Chapel Hill, NC

_______________________________________________
Rpm-list mailing list
Rpm-list на redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list

----- End forwarded message -----


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 232 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20010218/eca6fc92/attachment-0001.bin>