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@xxxxxxxxxxxx Box 90305, Durham N.C. 27708-0305
