Disappearance of Desktop Applications (firefox/thunderbird ...) from Repositories

T

tennea9

Hello everyone,

Can I know why Firefox/Thunderbird and many desktop applications have disappeared from the repositories (quaterly and latest) in version 14.1?

Did I miss a discussion? Is it due to an issue with a dependency?

Thank you very much
 
I had a hunch, I see a lot of messages related to various dependencies linked to these packages on the bugs mailing list. But given the importance of some of the packages, I wanted to be sure.
 
In light of the developers who tirelessly work on these dependency issues, whom I deeply thank for the immense work they accomplish each time, and despite the probably high number of posts on this same subject, I still do not understand why, on none of the FreeBSD repositories, "backup" versions of the most important packages are not present.

I understand that the community is particularly tolerant of these legitimate issues and agrees to wait as long as necessary for the brave developers to solve the problem.
I myself adapt when I can.
Without Firefox, let's use Iridium-browser in this case! Or a compatible Linux browser.

But it is common for problems to arise during dependency upgrades, taking important packages like Firefox/Thunderbird or dependencies for a desktop environment (KDE, for example, in the current situation) offline.

Is there no plan regarding this?
It would be really good... because now, the biggest browser/mail client have disappeared after all...
 
eternal_noob said:
Maybe just remove the old versions (including the dependencies) IF (and only if) building the new versions succeed?
Click to expand...
and holding up the whole ports tree being published as packages, just because some huge mess of a software project fails to build?
Also, given that I run FreeBSD on *a lot* more servers than desktops, I (and many others) wouldn't even consider a browser a "critical package"...

IMHO the current approach is the only correct one - if a port fails to build it simply disappears from the pkg repositories until it has fixed its (build) issues.
But don't hold up everyone else or (worse) keep old versions of dependencies around, which will cause an absolute dependency-hell if there are multiple versions available which are mutually exclusive and hence will nuke a lot more than just a single port from the system.

If someone wants to rather roll back to the last working/buildable version of a port, possibly also rolling back dependencies, just clone the ports tree, revert the commit(s) and build the port(s) and dependencies (or e.g. set up poudriere to build all your packages).
 
On a first look this current package fallout is rather huge. multimedia/ffmpeg isn't available anymore and that alone drags many desktop related package down.

Whenever such events happen, the explanations for why packages have to be removed from the repository when dependencies fail to build are sound and understandable. But then you realize that such events don't happen at that scale on other systems, and you start to question yourself: sure, but is this REALLY the best approach to handle such situations?
 
Yes KDE has also crashed.

I completely agree. And yes, it's a big failure happening right now, and fortunately, it's not frequent.

Similar to the Unix distributions page on DistroWatch, a table with the most used applications and information on their availability (or not), updated regularly, would be nice on the site (in addition to being good publicity!). It could help anticipate issues a bit. (Especially with an attached RSS feed).

I wanted to do an installation this weekend and it took me a while to understand where the problem was coming from.

Everyone can think what they want about the importance of Firefox, but it is a "basic" package on the vast majority of Unix-like OSes. Its essential nature seems hardly debatable to me. Everyone has their own use for FreeBSD.

And yes, there are always solutions... which are absolutely not simple to implement for the majority of users. For the more experienced, it's a usual scenario, we wait patiently and implement workarounds.

If you are new to the FreeBSD world and you encounter this problem upon entering the ecosystem... this kind of temporary "issue" can clearly be concerning.
 
This has been discussed in the past, in the same way that we have to build ourselves kernel packages like drm-*-kmod during the transition period between two minor release, we can't have multiple version of the binary packages.
There is not enough resources to keep a proper backup of old binary package.

The only way to change this, would be to increase the budget planned by the foundation, which can only happen with more donation.

Another way would be to have someone allocating the resources to have a server that store the backup of the official pkg binary repository. But beware that if you want an old version, you will have to downgrade all the corresponding packages.

PS: if we look at the Linux foundation, the yearly income is 262.6 million of dollars, while the FreeBSD foundation is at 1.268 million of dollars. So the Linux foundation get at least 200 times what the FreeBSD foundation gets.
 
monwarez said:
This has been discussed in the past, in the same way that we have to build ourselves kernel packages like drm-*-kmod during the transition period between two minor release, we can't have multiple version of the binary packages.
There is not enough resources to keep a proper backup of old binary package.
Click to expand...
I remember, lost the thread itself, though. ;)

And ideas I've proposed at the moment and now are both focused on minimizing redundant resources (by limiting to kmod ports only at the moment and by limiting to non-security, no-dependency-lib-bump cases this time). Looking for "well-ballanced point".

Anyway, these requires changes in infrastructure (ports framework and servers) and all would needed to be "sponsored" or "prized" work, causes, more donations for it required. May not so easy.
 
bsdcode said:
On a first look this current package fallout is rather huge. multimedia/ffmpeg isn't available anymore and that alone drags many desktop related package down.

Whenever such events happen, the explanations for why packages have to be removed from the repository when dependencies fail to build are sound and understandable. But then you realize that such events don't happen at that scale on other systems, and you start to question yourself: sure, but is this REALLY the best approach to handle such situations?
Click to expand...
ffmpeg disappeared a few years ago in latest,
and when i updated from quarterly to latest it removed all my browsers, video and audio players and obs studio

Which completely broke my system

i didnt think the issue would happen with the quarterly branch
luckily none of my packages have been removed, but this makes me nervous

i think im going to have to install Ubuntu on my back up computer a Macbook Pro Retina 2015

All 3 of my computers run Freebsd

Dell Xps 15 2019
Macbook Pro Retina 2015
Macbook air 2011

Not sure its wise to keep all my eggs in one basket
 
Well, in my case the problem is the missing vlc package and thus pkg wants to remove it along with obs-studio. I just say no... Unless someone blindly pipes a "y" in pkg they're safe (if it's even possible, I can't be bothered trying).
 
obs studio has a vlc source which lets you play videos in vlc and have them displayed in obs studio

the freebsd package of obs studio automatically installs vlc as a dependency because of this

obs studio shouldnt install vlc
because its not required to actually run obs, its only needed if you use a vlc source in your scene

in which case you could just install vlc

its just something thats always annoyed me since i dont use vlc
vlc isnt installed with obs on any linux distro i have used
 
Same goes for the useless pulseaudio dependency that is enabled by default - so just build it from ports without VLC and PULSEAUDIO options enabled and it won't drag in vlc and pulseaudio...
 
i use packages,
i could use poudriere to build obs but cant be bothered

so i just put up with vlc and pulseaudio
you have to manually start the pulseaudio daemon before running obs as well
 
NapoleonWils0n said:
its just something thats always annoyed me since i dont use vlc
vlc isnt installed with obs on any linux distro i have used
Click to expand...
multimedia/obs-studio seems to have an option VLC, on by default. At the same time, option PULSEAUDIO, on by default, too.
You can build it from ports yourself, turning the options off.
And this is one of the reasons that ports tree is disclosed to everyone in the world. Flexibility, with costs of time and disk spaces.
 
I understand the discussions about costs and I get it.
But the Linux world is gigantic compared to the small but very brave FreeBSD ecosystem!

Also, what if someone decided to set up a simple server hosting all the binary packages from the quarterly repository, with different versions as they appear?
 
You must log in or register to reply here.
Back
Top