reply: [Rpm-maint] Assorted changes in my rpm branch

[James Olin Oden]

On 12/17/06, Jason Corley <jason.corley at gmail.com> wrote:
> > Agreed. I'm happy to just wget an rpm before installing it, personally.
>
> This seems like a good reason to me to remove neon support from rpm.
> Why would a person want to do:
>    rpm -ivh http://foo.com/bar.rpm
> When they could do:
>    wget http://foo.com/bar.rpm; rpm -ivh bar.rpm

This is not meant to be incendiary, but your confusing your view of
what is easy and desiriable with everyone elses view of the same some
of whom may think differently with reasonable reason for thinking so
differently.   For instance, I could argue that having tools simply
support URL's is a good thing, since a URL is a very simple/portable
way of specifying the location of a particular resource (an rpm in
this case) and the protocol to use to aquire the resource.  Yes, you
can express it as a wget followed by an execution of rpm, but the
first use with rpm is very simple for the end user, and if they have
ever used a web browser intuitive.

That said sometimes things need to be simpler on the maintenance side
of things and I know for a fact that there is no end to possible
protocols that one might want supported, and futhermore they never
seem to be supported exactly the way everyone wants.  So removing the
functionality is a reasonable thing to do, especially when they are
likely much more important things you wish to support in rpm.

Even so, rpm I/O is a really good idea IMO if only that it tries to
provide a standard interface to files no matter what transport is used
to aquire the files, and attempts to use URL's as the user interface
to that functionality (which as I said is readily understood by many).
 Personally I think the issue that people really have with rpm i/o is
how over time it has picked up more and more 3rd party libaries, thus
requiring rpm to pick these up.  So if I may let me suggest a better
way.  How about providing some sort of driver layer in rpm I/O such
that when one build librpm and its rpm i/o component, none of these
libraries need to be on the build server even.  If you want the added
funcitonality is seperate from rpm in a discrete module that you may
or may not provide.

In order to do this you have to specify a proper API that these "rpm
i/o" modules must provide (which if you look in the code is almost
there in the numerous case statements).  The STDIO driver would be
only one that was there by default.  Others could be in the source
tree but should definately be able to be turned off (i.e. their
building) very easily.   Again, as I said in a previous email rpm i/o
as a library itself does not even have to live in rpm (albeit it would
have different name).

> I think you should take this to the next logical conclusion.  After
> all, I'm perfectly capable of just downloading a directory of packages
> and resolving the dependencies by myself, seems like a good enough
> reason to kill off yum and friends.  No reason to bloat a system with
> python when wget is all you need.
Not necessarily a logical conclusion in the "classical" sense.  More
like a subjective conclusion derived from subjective maxim's placed in
a logical frame work.  That said subjectivity is not bad it just can't
be mapped typically to all user experiences and/or desires.  So the
thing to do in that case is to make the "bloatedness" not required.
Someone wanting the "feature" can then have it, but someone on a much
more stripped down system, doesn't have to have it.  This is the model
the kernel developers have been going with for long time now if I have
observed correctly.

Again, this is not to "put down" your oppinion, only to suggest that
there are other reasonable ones to be had from the universe of
reasonable oppinions.

Cheers...james