Notes on Yum Changes

Sean Middleditch elanthis at awesomeplay.com
Tue Sep 7 19:19:31 UTC 2004


On Tue, 2004-09-07 at 20:06 +0200, Kyrre Ness Sjobak wrote:

> Yes, that is one way to solve it.
> 
> What i was more thinking about, was really "integrating" (sorry if i use
> the wrong wording) yum into rpm. Yum has an API, yes?

Again, why?  You don't get anything for this.  Just use yum all the time
and never invoke rpm.  This is similar to how most users in Debian
systems use apt-get all the time, but almost never directly invoke dpkg.
And dpkg has no apt integration at all.

The tools you use should be built on yum.  What you're asking for is to
allow tools to be built on rpm but have yum's features.  That's a bad
way to design the system, for many reasons, not the least of which is
because the package manager should be able to just do its job; adding
more meta-packager features to RPM is just going to increase the chance
of bugs (and bugs which can and will affect the core of the package
manager)

> 
> Only that will create a circular dependence rpm/yum - make it a compile
> option?
> 
> But something that WILL be needed if this actually gets implemented, is
> some "--noyumdepsolve" and "--silent-answer-yes" flags - rpm is very
> useful also in scripts. (is there some way to detect if a program is
> getting called by a script (non-interactive) or by an actual person on a
> terminal? If so, --silent-answer-yes should be default imo. That option

You can check if stdin is a (pseudo-)terminal or a pipe; the former
indicates a user, the latter a script.  Any time the user is directly
interacting with the app, they should be using a PTY/TTY.  Scripts may
still use a PTY however; it's good to always be able to explicitly tell
the tool that you're a script.

> could be _very_ useful when talking about rpm that require a license to
> be read etc. (ever tried installing the Macromedia Flash rpm's through a
> script? /me likes Dag Wieers, who makes good non-interactive
> flash-rpms...)

The problem there is that, put bluntly, RPM sucks for applications.  It
is a low-level packaging tool intended for bundling the components of a
distribution.  It never was intended for third-party applications, and
to this day still has huge problems supporting them, as the situation
with Macromedia demonstrates.

For license agreements, RPM would need meta-information to carry the
full license text and allow a package to note that agreement is
required; this would be done before any of the package installations
even start.  Currently, you'd have to put this in a script (and pray you
made it portable enough *and* not use any binaries in your package,
since it isn't unpacked yet, and make it pretty, and make it
consistent... it's just not feasible) which would a) be executed
sometime during installation, and b) have to report an error to rpm if
the user declines, which would most likely cause all sorts of
"Installation Failed!!!  Here's some geeky nonsensical techie debug spew
you, the user, don't understand or care about, because you are aware of
the fact that you said 'No':  <rpm error report>" dialogs or console
messages to appear.

There are still then problems stemming from the fact that every version
of every distribution is incompatible due to either developers not
versioning their ABIs right, or packagers taking perfectly well
versioned libraries and tools and putting them into poorly versioned and
inconsistent packages (like the broken curl RPM in Fedora), but that's a
whole different topic. ~_^

> 
> Ofcourse it is possible to tell people to use yum instead of rpm - but
> how nice is that? "Hey all you people, forget about rpm - always use yum
> instead!!" - or not? "rpm -ivh two-lettersTAB" is something that is
> built into my fingers... But a new tool could work (something like
> "rpm-depsolve -ivh my-package.fc2.rpm"

If you're alright with requesting a tool like 'rpm-depsolve', I don't
see at all how you can argue against just using yum.  ;-)

> 
> Only problem now is actually finding a good programmer, and a good way
> to do this.
> 
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.





More information about the fedora-devel-list mailing list