[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: FC5 - T3 - Had enough. Package Managers, Yumex is crap.



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]