ToddAndMargo via users writes:
On 3/29/19 6:34 PM, Sam Varshavchik wrote:xfce 4.13 has been fine for me.4.13 has been a pain in my neck: Libre Office pulses at me https://bugzilla.xfce.org/show_bug.cgi?id=14863
That's the one that I find the most annoying. But it's not a showstopper.
Black backgrounds in panels https://forum.xfce.org/viewtopic.php?pid=50266#p50266
I've noticed some occasional glitches like that.I guess that my standards are pretty low. I don't mind minor, non-critical bugs like this, and just write it off as a cost of doing business.
Clicking on MTP device crashes Thunar https://bugzilla.xfce.org/show_bug.cgi?id=15172
That's probably the only one I'd consider to be a showstopper. Reminds me of a bug that tipped the scales for me in the other direction: way back when, Gnome's file manager decided one day that my usb-storage mp3 player was an MTP device. Hillarity ensued. The bug collected dust for a year, before I ditched Gnome and went with XFCE, after I noticed that the lightweight XFCE build I installed on a netbook happily mounted the same MP3 player.
Ditching the unusable "usability-improved" Gnome 3 was also a bonus. Never looked back.
Default browser does not work https://bugzilla.xfce.org/show_bug.cgi?id=15238 AAAAAAAHHHHHHHHHHHH!!!!!
I don't think there's a viable way to down or upgrade xfce. If it was only one RPM, I would seriously look into rebuilding it. But it's quite a few dependencies, and probably a whole pile of packages needs to be rebuilt.
If I were to try this experiment, this is how I would proceed (of course, its unrealistic to expect Joe sixpack to put up with this, I understand this):
1) Grab the newer XFCE base library package, and attempt to hack the current XFCE source rpm to build it. There's a reasonable chance all that needs to be done is to bump the version number in the source RPM. Assuming that the rebuild succeeds (and if not, one will simply have to figure out why, and there's no cookie-cutter recipe for that, you're way off the beaten path): I would try a test upgrade, using rpm with the --test option.
2) I would actually think that a dependency failure would be the best result. This will tell you which packages need to be rebuilt next. At this time I would switch to mock, install the upgraded xfce packages in a mock buildroot, and proceed to attempt to build the newer RPM of each package.
3) If there wasn't a dependency failure, I would proceed cautiously. Upgrading the base package would be ok, but it may or may not solve your issues, in which case you'll have to guess which next part of the stack you want to upgrade.
If I were to proceed at all, I would go the upgrade rather than a downgrade root. After downgrading, dnf will keep wanting to upgrade xfce every time. I think there's a way to lock it.
One possible answer to this conundrum is the modular Fedora effort. I've only been following it with half an ear, but at least on paper it seems to address this very issue: offer alternative version of Fedora components. But someone has to volunteer to maintain all of that stuff, of course…
Attachment:
pgpAVa1ixPRBN.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
