gnome-vfs not in Rawhide?

[Jeff Spaleta]

On Apr 7, 2005 11:59 AM, Mike Hearn <mike at navi.cx> wrote:
> The definition of what's "core" and what isn't seems pretty vague to me.
> There's no need to drop things as more stuff is added, just be more
> conservative about adding things! There's no need for FC to have loads of
> apps out of the box. It's more important IMHO that it's easy to use and
> Just Works.

stagnation... thats what you want. Following your logic we could never
drop an application, or a library to make room for any new
functionality or streamline the system at all. I take it in your world
view we should be including a 2.4 and a 2.2 and potentially a 2.0
series kernel for "compatibility" reasons. I mean hell, I know there
are some proprietary and open source kernel modules that are well
tested and work with 2.4 kernels that havent been ported to the 2.6
kernels yet. Even more so when the 2.4 kernel was dropped outright. 
If Fedora Core stressed backwards compatibility at the distribution
level as strongly as you do, we would never have a 2.6 kernel by
default.....stagnation.

Your definition of "just works" is different than mine. I do not
consider the full space of all previously written codebases when i
talk about "just works." Shall I complain about that fact that the old
oneko packages from rhl that i relied on no longer work?  Or the fact
that the absoft fortran compiler doesn't work without compatibility
packages being installed?  Solve the general forward looking problem
of getting compatibility elements from Extras instead of demanding the
set of packages in Core remain stagnant and you'll be everyone's hero.


> There's no way to do this currently. 
Then build one. Some compatibility items will be moving to extras. If
you feel its too cumbersome to people to interact with Extras to find
those compatibility pieces.. build the better interface and mechanisms
to help those users out.  I think its far far too late in the game to
be complaining about how compatibility libraries are treated since
they haven't been installed by default up till this point. Its going
to be far easier for you or anyone else who thinks compatibility
libraries is a priority to engineer a solution that works with Extras
than to expect priorities to change.  But hey, if you want to try to
change the course of a river by shaking your finger at it on the
riverbank.. please go right ahead.

> Possibly if distributions had
> provided a single consistent packaging scheme from the start, 
> would never have been written. But it didn't work out that way, and now
> we have a legacy issue to deal with. Sucks but that's life. Maybe there
> are lessons to learn here.

Yep and its going to be dealt with by moving some compatibility
libraries into Extras and having users install them as needed, instead
of installing them by default. So anyone who wants to make it easier
to get compatibility elements installed should focus on making it
easier to interact with Extras as needed when needed.

> Yeah right, just like MacOS X is stagnating. Whatever.

That's an obnoxiously silly comparison. MacOS X is a for pay product
that encompasses non open software elements which are developed in a
highly closed process. apples to oranges comparison. Fedora's long
term development priorities are publicly available as a guidance for
this project, MacOS X's are not.
And I dare say, as an individual you have far more potential to impact
what goes on in fedora through your individual contributions to any
specific piece of distribution than you have with the direction of
MacOS X development.

-jef