Notes on Yum Changes

[Kyrre Ness Sjobak]

tir, 07.09.2004 kl. 21.19 skrev Sean Middleditch:
> 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.  ;-)
> 

Hmm... somhow using yum to install a local package feels wrong... Hmm...
think ill acctually have to write some prototype stuff, then.

rpm-depsolve, here i come! :P

Always wanted to create some "core" utility...

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