On Wed, Oct 15, 2003 at 06:00:03PM +0400, Grigory Bakunov wrote:
> Michael Stenner wrote:
> >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.
> >
> >
> So, you'll see redhat kernel package? It's add lot's of stuff to kernel,
> including new memory management model and sheduler.
Those are both changes to HOW the kernel does things, not WHAT it
does. Almost nothing behaves qualitatively differently with these
changes. It may be a little faster or slower for different tasks, but
they all STILL WORK. You won't see redhat adding its own system
calls to the kernel any time soon.
> >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.
> >
> Yes but if lots of users like this functionality why this changes not
> in main branch? :)
That is a different conversation. All that's relevant for this
conversation is that they're not.
> > If your
> >srpms included tarballs from linux.duke.edu/projects/yum + patches
> >of this nature, then I would not call it a fork either.
> >
> Okey, so, how can i give to users way to use CD and GUI with
> yum? I can't persuade Seth to include all of my patches cause it's
> don't realy need for lots of peoples in US. For example
> yum still traffic-hungry application. Yum still doesn't work
> well with CD etc. I absolutely understand what in US it's
> doesn't matter cause low cost of traffic. But for example
> in Russia and Ukraine we pay more than 0.1$ per megabyte.
> And our salary between 100 and 500 dollars :)
Do what you need to do. If you feel you need to give your users a
packaging tool that's different from yum, then fine. I don't have a
problem with that. That's the beauty of the GPL, and we like it that
way. I only spoke up because you're saying that your "yum" is not a
fork when its functionality and interface differ in major ways from
yum.
I will also remind you that we _LIKED_ the idea of the removable media
behavior. We would just like to see it implemented a little
differently. _A_ removable media patch will probably get in, but it
may not behave in a way that's compatible with your first submission.
> Another example is this bored i18n patch.
This is an example of something that I think is fairly reasonable as a
"packager's patch". It does not change the functionality, config
syntax, or behavior of the program. It only changes the language of
the output.
> I realy don't understand what i need to do. If i can't produce
> rpm with my patches, did you see any other way to add functionality to yum?
> I don't try to flame but i realy want to know how to do it.
I'm not telling you that you can't produce rpms with your patches or
anything else for that matter. You will not be receiving any
cease-and-decist letters on Duke letterhead :) The worst that will
happen is that you will get fewer smilies in your inbox.
I would (personally, can't speak for others) suggest that you change
nothing unless you find a solution that works better (or at least as
well) for everyone. Let me brainstorm for a moment. I'm not as
familiar with the subtleties of packaging, so some of these may just
be stupid.
1) rename the package to something like aspyum or yum-asp, etc.
The executables could remain the same. The packages would
conflict, but that's OK. Doing an obsoletes might be a bad idea,
though.
2) distribute a yum that is feature/syntax compatible, but
distribute another "supplemental" package.
For example, a yum-aspgui or something. Yum DOES support cdrom
access (via file://), it just doesn't currently support
automatically detecting what cdrom you have/need, ejecting,
mounting, etc. If you have a gui interface that supports this
then fine.
Nobody cares if you distribute other programs. It's only if you
put them in YOUR package when they're NOT in the official yum
package that things get a little ugly. Ideally, these other
programs would work with the official yum, too.
> Thanks for answers!
You're welcome. It can be tricky to meet all the various
functionality and tidiness goals in a given situation. Hopefully,
this conversation will get everyone a little closer :)
-Michael
--
Michael Stenner Office Phone: 919-660-2513
Duke University, Dept. of Physics mstenner@xxxxxxxxxxxx
Box 90305, Durham N.C. 27708-0305
