[Yum] Removable media support in yum

Michael Stenner mstenner at phy.duke.edu
Wed Oct 15 13:33:19 UTC 2003


On Wed, Oct 15, 2003 at 04:54:55PM +0400, Grigory Bakunov wrote:
> Michael Stenner wrote:
> 
> >If all of the patches and features were guaranteed to get into yum,
> >then I would agree with you.  However, if you release a program based
> >on yum that has code and functionality that never appears in yum
> >itself, then that is by definition a fork.  If you do that, then to
> >avoid ambiguity, you might consider naming it something other than
> >"yum".
> >
> No-no-no!
> I mean what i only want to build package with some patches
> (like RedHat and other distributors do). Look for example
> on emacs or kernel packages in RH.  It's contains tons of patches
> but still named as 'emacs' or 'kernel'. Yes, i understand what
> some patches can be added to main YUM.

Bugfixes and changing default settings are one thing.  Adding major
functionality, config syntax, and new executables in /usr/bin/ are
quite another.  These are pretty big differences for two packages with
the same name and version number.

You'll rarely find two packages of emacs with the same version that
cause the program to fail utterly and completely when you switch, or
to have major functionality disappear.

I understand your point, but I think we're drawing the line in
different places.  I thing http keepalive (or reget) would be a fine
example of a 'patch'.  The config, interface, and user experience is
the same with or without it.  It's just a minor performance
difference.  You can add it or drop it and nothing breaks.  If your
srpms included tarballs from linux.duke.edu/projects/yum + patches
of this nature, then I would not call it a fork either.

					-Michael
-- 
  Michael Stenner                       Office Phone: 919-660-2513
  Duke University, Dept. of Physics       mstenner at phy.duke.edu
  Box 90305, Durham N.C. 27708-0305



More information about the Yum mailing list