Axel Thimm wrote:
On Fri, Feb 24, 2006 at 06:51:53PM +0100, Arjan van de Ven wrote:
On Fri, 2006-02-24 at 00:19 +0100, Axel Thimm wrote:
I was about to submit a bug report that neither does the installer
simply allow my to throw the full contents of the DVD onto my disk
anymore, nor do any of my kickstart files work with FC5 anymore, when
I found that this was not a bug or a temporary shortcoming, but was
done on purpose (at least according to a post by R. Sundaram which
sounded quite authoritative).
you assume it's even possible to (sanely) install all packages, which I
think already was not the case for a while, with an increasing number of
special cases to keep the "almost everything" install working....
(kernels and other rpms with conflicting files etc etc)
Yes, I know, that was always the case. And "everything" meant just that.
An everything install option should had been even a must for the test
releases. There are bugs that emerge only in bad synergies of
packages.
I just installed FC5t3, clicked on any funny checkbox there was and I
get a system w/o emacs ...
BTW I found a bugzilla entry [2] which contrary to R. Sundaram's
report [1] stated that this was just due to missing yum glue and not a
permanent state:
[1] http://forums.fedoraforum.org/showpost.php?p=438011&postcount=4
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177621
Let's hope a coming rawhide cut will have this restored in one way or
another.
So basically lack of resolution in the yum program and hesitation for
upstream to compromise on additional patches to enable more user
discretion is the problem. Also the policy for Fedora to track upstream
as closely as possible is a drawback to supplying a patch to resolve the
problem.
I admire the upstream work and strong adherence to the individualistic
goals upstream desires. I however see the benefits for everything
installation as a possibility "best effort" dependency and installation
efforts to be crucial for managing a system. Divergence from upstream
might allow for a more controllable and better suited final product.
If further divergent development is needed, it might be wise to follow
an independent direction and diverge as needed.
Basically, the goal of the project to keep in line with upstream is
great and the best policy for a more unified look for development of
programs which are included within the distribution. The only problem
with complete reliance to conform with upstream policy is you get what
they decide to accept. The pitfalls are you get a less capable updating
mechanism and in the terms of GNOME, whatever upstream decides to push
onto the downstream users/developers.
GOALS:
- The ability to install everything if desired.
- The ability to have your system install all the packages which have
satisfied dependencies resolved.
- program behaviors to satisfy the user instead of "best for the user's
own good".
- not having a system that pretty darn well matches MS in downright
disgraceful behavior. (KDE)
- Not having a desktop where customization and completely stupid ideas.
(gss and nautilus browsing behavior) are pushed into the desktop to
spite user feedback to the contrary. (GNOME)
- A desktop which is customizable, feature rich and incorporates within
it what is useful and attractive to the end user.
Sorry, I'm stuck in KDE and am experiencing a lot of MS windows behavior
because metacity is crashed in GNOME and the windows switcher or program
contol are gone without a decent windows manager. I believe it is time
to depart from metacity and incorporate enlightenment or another window
manager. Metacity even cut out the windows managing feature. This is
base for what the program is supposed to accomplish in the first place.
Simplicity is not the answer. Upstream co-operation with project goals
and usability and customizability are better served with divergence from
upstream.
Jim
--
"One lawyer can steal more than a hundred men with guns."
-- The Godfather
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list