Daniel B. Thurman wrote:
Jim Cornette wrote:
Is it the version of yumex from Fedora Extras development?
Yes, I used the version directy out of the Fedora's Extras
development area, I believe. This is actually the first time
I took took the time to play with a Test version of FC.
Thanks for the answer to where yumex was pulled from. The Fedora-Extras
development repo should sync with FC5 test releases. I know that one
Fedora Extras program, gnomad2 (for creative Nomad jukeboxes) caught a
change from FC5 that concerned hotplug's removal from the distro and now
works better than before the removal of hotplug effected the Fedora
Extras program.
Yumex is able to have bug reports through bugzilla.redhat.com also. It
worked to submit the problem (or attach to a report someone else opened)
to get that change effecting my desired program to work once again.
About test releases. This one is mild compared to earlier test versions.
Phoebe for example was my first interactive test release that I tried. I
finished update with a broken X server, blew my system away using
apt-get and answering yes to the extreme package removal in order to add
one package and a host of other mishaps. The test releases are a lot
easier to use now with yum dep resolving and reports generated when
development is rebuilt. FC5 test cycle was the easiest to install and
deal with me in relation to other Development cycles. Some even
suggested adding mishaps more often to distract those thinking the test
release was supposed to be stable. It does not break now as often but
does break in serious ways from time to time.
Restarting the package programs, would perform a yum clean up
effectively wiping out the 12 hours (3 times) or so downloaded
package I was looking for the designer of these package program
and wanted to say a few unkind words. I was definately displeased.
Why do the designer of these package programs decide to do an
automatic cleanup and don't even bother asking the user first
is beyond me.
I usually run yum clean all after verifying the install went well.
Usually there are still packages cached in
/var/cache/yum/development/packages after pirut exits. I did not realize
that pirut would do a cleanup. This is bad if a user wanted to copy the
rpms that were downloaded to media for future upgrades on other
non-networked machines. If it does actually cleanup, filing a bug report
against pirut would be wise. WE cannot do much more than side either way
or another action. Updating the program is easier if the designer knows
about the bug.
Yes, that is what I am saying. Both pirut and yumex seemed to do
the same thing. About pirut, it is very non-intuitive - especially
where it does things in stages and what surprised the heck out of
me was when it completed a download, the dialog would disappear and
then you are staring at the main pirut window
Pup used to just exit after completing a successful install. This left
one to wonder if it aborted before completion or finished successfully.
The successfully completed task followed by an exiting of the
application is better than not knowing for sure if the update completed.
If pirut is misleading, the developer of the program seems open for
suggestions from time to time for improvement.
-- it took me 6-8 times
of going through this before I realized that after the download dialog
quit, I was supposed to hit the <Apply> button AGAIN (Yes, I did that
earlier which started the download in the first place. I *thought*
the download died - so I terminated pirut and restarted the WHOLE DARN
PROCESS again with the selection of packages etc. etc. it was just
frustrating - before you say - you dummy! -- *think* about it - if
you just did not know what to expect next - what are you supposed
to THINK what to do next? Yea, Yea... it got me good.) When the
"Updating Software" dialog runs to completion, clicking OK terminates
the dialog window AND pirut. Grrrrrr..... I wasn't done YET!!!
VERY VERY COUNTER INUITIVE!! Are these developers experienced with
GUI interfaces and taught how to be INTUITIVE???? I guess in this
case, the answer is NO WAY.
I believe it is what is intuitive to one person is not intuitive to
others. I received user feedback on some things that were intuitive to
me, but not intuitive to others on work related projects. I made the
change to reflect the user level intuitiveness instead of mine and the
program was better.
I am with you on agreeing that you select the packages, start the
download, you expect for the whole action to be completed. Once the
package installation is completed, you should be acknowledged of its
success. After that, you should be in a program condition where you
could hunt and install other items and apply them to the system. Once
you choose to actually quit the program, it should exit as desired.
Filing a bug report??? I was just too tired - peeved as hell - and
need a break - my eyes are bloodshot. My wife pissed at me. Someday
I will file the bug report.
A long chain of events! The bug will probably be reported by others who
experience similar dissatisfaction with intuitive application behavior.
If you have time to file a report, it should add to the requests to make
it act in a better manner.
Never mind that this is T3 - this is a really horendeous way
to treat a tester when they cannot even download the updates
or packages needed to get FC5-T3 updated to a useful state.
Try entering a test release where starting X from a root user absolutely
trashes your system. I rarely started X as root for normal activity, I
now do not start X as root at all. (Except system-config-display, if
that counts) The testing phase does add good practice by example. :-)
Maybe the best thing to do is to download the RPM files and
do a rpm manual install and toss these package managers
completely out of my FC5-T3 system.
If you want to install off of the local media, you can make a repo file
or edit the link to baseurl=file:///media/<mountpoint-for-DVD> and run
yum, pirut to install desired packages from the install disc. (dvd
anyway). I had to set up a local repo to update a non-networked computer
from FC5T2 to FC5T3 because of a USB DVD problem and the upgrade took.
It did take a really long time to complete, but it did complete.
Well... I had to learn how to use pirut first :-( Second, I trusted this
tool would do the job (and that I understood how it worked), so after
working at it and toiling over repeat GB downloads and several days lost
I guess in retrosect this is a good idea. Yes, I will do that for Test
releases of FC. sigh.
Since the package manager uses yum, I believe the concept was not
thought of for local installation off of the disc sets. The addition of
a selection pulldown for where you want to download packages sounds like
a great addition to add to the package manager. Why download from the
Internet what is already available of local media? I recall some
discussions on the fedora-test list or bugzilla for dealing with dialup
users concerns and those without network connections or tricky secure
networks.
Hell, with yumex, I tried to select 5 packages - it went through
the whole thing up to transaction testing and the whole program
dropped dead, i.e. the entire application program disappeared
and no trace/log of what the heck happened. Yumex is in serious
need of repair - it is extremely unstable. Package Manager is
probably more stable but is dumber than an ox.
I'm from the city and never had to deal with the intelligence or
stubbornness of an Ox. I'll take your word for it.
A select all for different groups would make things more bearable on the
installer. Pirut pretty much mirrors what is available from the
installer except there is a list feature where you can pick items that
are not in any particular group. I like pirut and it performs the job
well for my purposes. I don't think that the program should be
criticized harshly. I do think that nicely toned bug reports to
bugzilla.redhat.com and component pirut would aid in improvements to the
program.
Well... with what I was going through, I hope you understand that once
you figure out how the tool is supposed to work, then perhaps you are
right. It has some subtle nuances and I am sure it will throw off some
people who are not used to it at least for the first time. I was flaming
mad due to all the trip ups, gotchas, and long download times I am sure
I must have dropped my marbles somewhere and wanted to rip off someone's
head.
The issues you presented are fairly civil. I believe they would be
considered for inclusion in future releases. I believe a selection for
enabling or disabling repos through the manager and a default local.repo
are good features to add to the program manager.
I think I will stop here and take a long break. I will let the
other testers do the fun part of testing. I am just not going
to continue to rubber hose my self and scream 'mea culpa'.
Filing bug reports against the problems which you noted would be great
to try to eliminate them for FC5. I don't think a large amount can be
done since the freeze is today and FC5 should be out shortly after.
The trouble to file bug reports might get improvements added after FC5
is released though.
Sigh... I sorta did with this message. I think everyone has read this
message and gets it.
Most developers do not linger in fedora-list because of the high list
volumes distracting from their productive time and time they could use
for upstream interaction. Several redhat employees do participate in the
discussions for issues where their input would be helpful, usually
related to their area of specialty. Their replies have helped me in a
lot of areas.
For the bulk of the list members, changing the way the application is
configured is not something where assistance could be given. We could
post patches and what not, patch the source and offer alternative binary
repos. I doubt that most of us would go that far though.
Thanks for taking the time to test the distro to be. It looks like you
might be holding back on upgrading for awhile.
Well... never say never. A festering burr needs to be removed so I
manually used pirut and piece-meal-at-a-time downloaded and updated
ALL (but the conflicting) packages and some that was obviously not
what I wanted. It was slow, tedious, but after 5 days - I did get
the job done as far as installing FC-T3 This is nothing to say about
anything else cuz I haven't started yet.
five days invested into installing the distro as you want it is a bit of
a long time. Hopefully this is not going to be a major trait for the
bulk of those who do upgrade to FC5 in release date or shortly thereafter.
I mostly like what I have experienced with the test distribution. I did
not like certain additions and deletions of programs and such. I
expressed my likes/dislikes and realize the distribution to be
marketable for a wide range of users, certain programs have to be
eliminated or made absolutely unexciting to be less offensive to the
mainstream. Personally, I find the elimination of certain programs to
cut away at the personality of Linux distributions in general. I can add
what I need. Those who want to make the distribution boring can become
satsfied and developers can hide graphics defects by not exposing the
cards to tests.
I admit that the FC5-T3 is at least a pretty GUI - but - I still think
that there needs to be a better standards and that anything to streamline
the installation process so that installation is as painless as possible,
is INTUITIVE that my 5 year old kid can whiz away and do it. Pirut looks like
it was designed for the visually challenged - I mean these fonts and icons
are HUGE - imagine what this might look like on a 640x480 screen! :-)
I believe the icons and themes are being worked on by those who
customize the artwork for applications. I ought to try 640x480 just to
get te visual impact for the large icons presently selected. :-)
I liked the layout of of yumex as it was CLEAR what was being
selected in the Queue.
As for pirut - when you make your package selections and once you hit
that Apply button, any conflicts or problems after that cannot be
deselected! You CANNOT backtrack!! You HAVE TO START COMPLETELY
OVER!! Now - I hope you see WHY I said - piece of **** - bad design
planning.
I believe that once the package resolution is started, the current dep
listing is used. I am sure that when a conflict is encountered, a
refresh for the deps should be automatically tackled and the conflicting
package should be able to be not selected without a need for a program
restart.
If yumex was stable, I would choose it hands down over
pirut only because it is MUCH more intuitive IMHO. You CAN backout
your package selections and try again but more nicely - you can see
the OUTPUT to determine the conclicting
package
and make informed decisions all while the program is still running.
Answered above.
Jim
Had enough,
Dan
Thanks for responding, and I hope to be more civil in the future and first
consult my therapist before flaming off again :-)
Dan
Sometimes the more aggressive postings add a bit of life to a list
environment. :-)
Jim
--
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
