Fedora 33 Beta To Be Released Next Week

[Anvil]

No. If the installed version is newer than the version in the repo it just won't install it. I am running FF 80.1 on my FC33 desktop.

im afraid it'll downgrade your firefox

[pipe13]

im afraid it'll downgrade your firefox

I'm not. Has this actually happened to you? Unless you explicitly specified "dnf downgrade firefox"? In my years of experience, I've never seen dnf or yum automatically downgrade an installed package A. They might fail to install some other package B that depends on an older version of package A, or refuse to upgrade A if B depends on the current version of A. But dnf/yum won't downgrade A unless you tell them to.

Edit: Ah, I forget your context. You posit system "upgrading" to FC33-Beta from a perfectly serviceable FC32. In that case all bets are off.

[MadeUpName]

Trust me it isn't an issue. On previous upgrades between releases I have had to actually pull out some packages because they were to high a version and packages that were being added or depricated and replaced were unable to meet their dependencies. What happens when you do an upgrade is is libresolve calculates what is needed and what isn't. If the installed version is a higher version than the one in the repo then it isn't needed. But you don't have to take my word for it. Do this.

dnf upgrade --releasever=33

It will spit out every thing it is going to do. Then press N and it will quit with out installing. Go have a beer think about it and decide if you want to go ahead.

[You-]

As I recall, there were some oddities being reported with certain (non-default) configurations of Silverblue (/boot being a directory and/or a subvolume) and BTRFS (as I recall at least one of the bugs was reported as not being BTRFS specific), and various tickets against anaconda, and ostree, and probably others, have been opened (some have probably closed, as I have not been following the work closely).

Where do you follow the development? A year or so ago it seemed easier to follow, but now it seems to have scattered and I cannot find any central location that is easy to track for updates and plans.

[Anvil]

Problem was Firefox failed to build with LTO support by default enabled and the version in the update come with that disabled function. Let remind we are talking about Beta Release where users should expect bugs and regressions and report them.

should be better , then why not call it an " Alpha " if there are so many bugs in it, a Beta should be somewhat stable, not alpha quality

[pipe13]

Those who can, code...

[ehansin]

Yes. Here's a link.

Thanks, just what I needed! I know it was possible, I didn't know about to a beta, but like yes ("You can also use 33 to upgrade to a Branched release...")

[ehansin]

Once the bits make it to the mirrors (and the bits should be there, but your mirrors may vary), you *should* be able to do a `dnf system-upgrade download --refresh --releasever=33` (followed by the system-upgrade reboot to actually do the deed) if you really want to do an upgrade. As always with any Beta your system could end up broken (caveat emptor).

Thank you as well. I don't mind if I break it, this install is more of a testing ground anyway. But I do plan on a reinstall with 33 proper and hope to use it more for development stuff, etc.

[JackLilhammers]

I know, right. But how would something like that even work? There's multiple rifts in the Linux UI community. CSD & SSD, Header Bars & App Menus, Text & Icons, X & Wayland, C & C++. There are three prominent toolkits: GTK, Qt, EFL (yeah, I know. it's more like 2.5); each with their own goals and ideas. How do we get all of them to agree on standards?

I was always hoping that Wayland would solve some of the UI fragmentation by defining standards. Unfortunately they decided to kick the can to the UI Toolkits and Desktop Environments so now we have umpteen different standards. I feel like any attempt to make a way to unify the toolkits will end up like the XKCD standards comic where we'll have 13 different UI unification methods and RHEL will back one, SUSE another, Debian a third, Ubuntu will use some homegrown method (and abandon it 3 years later), and Arch will include all with some wiki pages to tell us how to configure them.

That would have been nice. IMHO that's just another proof that the big players in the Linux world just don't care about the UI.
Linux dominates on headless servers, but almost nobody uses it as a desktop.
Why should Red Hat or Canonical or SUSE (or whoever) strive to fix something that has no market anyway?
They couldn't even come up with one solution to the backward compatibility problem...
There was already 1, but we had to have 3 :'D

[skeevy420]

That would have been nice. IMHO that's just another proof that the big players in the Linux world just don't care about the UI.
Linux dominates on headless servers, but almost nobody uses it as a desktop.
Why should Red Hat or Canonical or SUSE (or whoever) strive to fix something that has no market anyway?
They couldn't even come up with one solution to the backward compatibility problem...
There was already 1, but we had to have 3 :'D

At least we have Roman and his work on Disman and KwinFT. That's a step in the right direction and hopefully more DEs will pick it up versus reinvent the sudo.

You know, totally unrelated, but I haven't used the term wheel when relating to root in a long time. Suppose that's a Linux vs BSD thing these days.