editors/libreoffice disappeared from ports

sremick said:
Surely there can be a logical fix here (in the tools) to address this.
Click to expand...
sremick said:
So if an included core userland tool is having unexpected behavior, then that would constitute "FreeBSD having unexpected behavior".
Click to expand...
Here's my personal opinion on the matter: You ask pkg(8) to do something. It tells you "yes I can do that, but I'll have to remove these packages. Do you want to proceed?". You then tell it to proceed. What is there to fix here? In my opinion the tool performed exactly as per expectations.
Lets compare that to a situation where you didn't properly save a document in Microsoft Word or Adobe Photoshop. On the next startup, the software will tell you: "Hey, I have this file recovered for you. Would you like to discard it?". You click yes. It's gone. Is anybody complaining about that?

If the idea is to present the user with more warnings or similar we're basically moving towards an environment where one needs to put a disclaimer on a microwave oven not to dry your dog in it or a printed warning on the cup of the hot coffee you ordered at McDonalds saying that it's actually hot.
What would be next? Every time the user modifies the firewall configuration it should tell you "oh boy, you open ports and stuff, this dangerous!"? Even if, at the end of the day it would ask you "do you want to procedure?" the same way that pkg(8) asked that. If you say yes, there's nothing that can help you.

The important part here is: The user was informed and the user made a choice.

The scenario we're encountering here is simple: The libreoffice installation present on the system in question had a dependency that would no longer be satisfied (or would conflict) during the upgrade. There is no other sane option than removing it (or the user locks the packages and prays to the gods of ABI compatibility).
This is basically what cracauer@ is hinting at. It's not a FreeBSD problem, it's a core problem of applied computer science.
The only way humanity has found to work around (!) this issue is by means of bundles/flatpacks/snaps/static-link-everything which come with their own problems.

sremick said:
If I used cp to copy a file and it deleted it instead, I too would be upset. And even if the cp output said, "ok I'll copy your file but I'm going to delete these 3 other files. Is that OK y/n?" I wouldn't ok with that either. cp shouldn't delete files. And in the opinion of several here, "pkg upgrade" shouldn't delete packages either.
Click to expand...
So if you use cp(1) to copy a file to a destination that already exists (e.g. "overwriting an existing file") - how does your logic play out here?
Code: 
echo Hello > foo
echo World! > bar
cp bar foo
cat foo
Would you also blame the cp(1) tool? :D

In any case, I don't think that the attitude in this thread is helping anybody. Let's try to stay nice.
 
sremick But none of that has happened. The only thing that has happened is that the package isn't available because there's a build problem so it can't be downloaded and installed. How we got to the point that FreeBSD uninstalls and deletes software from all that, I don't know.
 
drhowarddrfine said:
sremick But none of that has happened. The only thing that has happened is that the package isn't available because there's a build problem so it can't be downloaded and installed. How we got to the point that FreeBSD uninstalls and deletes software from all that, I don't know.
Click to expand...
Actually, as with the other users, I used to have LibreOffice installed, and no longer do. I confess: I don't pay super-close attention the long lists I'm presented each time where pkg tells me what will get upgraded, what will get re-installed, and will get removed because I've put faith in pkg that it knows what it's doing and 99.9% of it is library dependencies that don't mean a lot to me.

So we have more than one user experiencing exactly this now, and record in this thread of it happening (twice?) before now.

And jbo: with all due respect, I was making an analogy to make and clarify a point. Just because my analogy is not iron-glad if you extend it ad infinitum to all nuances doesn't make my point invalid. I will allow you that there seems confusion as to what is actually being talked about here, with one faction upset that X happens, while the other faction defending that Y doesn't happen. You might be in the camp of "a broken port shouldn't be available to install from packages and shouldn't become available again until the issue is fixed" which I 100% totally agree with. But that's not what the frustrated folks are saying. We're trying to tell you: a working install of LibreOffice was uninstalled because of this, this shouldn't be expected behavior, and it has happened before. And I've only seen it happen with LibreOffice.

Fact is, the whole reason I piped in on this thread is because I was subscribed to it due to being bitten by this myself the first time around. I subscribed because it happened to me and I wanted to follow the discussion back then. Then suddenly I see activity on this thread again, so I check my installed ports and sure enough, LibreOffice (which 100% had been installed before because I use it) is gone again.

I feel the tone of this thread could significantly improve if we were all even on the same page talking about the same thing.
 
Luckily I have a long history in my terminal:
Code: 
[strand.138] $ sudo pkg upgrade
Updating FreeBSD repository catalogue...
pkg: No SRV record found for the repo 'FreeBSD'
Fetching packagesite.pkg: 100% 7 MiB 2.3MB/s 00:03
Fetching provides database: 100% 18 MiB 636.2kB/s 00:29
Extracting database....success
Processing entries: 100%
FreeBSD repository update completed. 33996 packages processed.
All repositories are up to date.
Checking for upgrades (10 candidates): 100%
Processing candidates (10 candidates): 100%
The following 11 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
libreoffice: 7.5.5.2_3

Installed packages to be UPGRADED:
assimp: 5.2.5 -> 5.3.1
boost-libs: 1.82.0_1 -> 1.83.0
dav1d: 1.2.1_1 -> 1.2.1_2
ffmpeg: 6.0_2,1 -> 6.0_3,1
libcmis: 0.5.2_8 -> 0.5.2_9
libixion: 0.17.0_4 -> 0.18.1
liborcus: 0.17.2_4 -> 0.18.1
libplacebo: 6.292.1 -> 6.338.0
py39-qt5-sip: 12.11.1_1 -> 12.12.2
py39-sip: 6.7.9,1 -> 6.7.11,1

Number of packages to be removed: 1
Number of packages to be upgraded: 10

The operation will free 393 MiB.
30 MiB to be downloaded.

Proceed with this action? [y/N]: y
So, we can't complain that there was no warning, but like others, I just trusted that pkg(8) was not going to nail me when I thought I was doing an upgrade...

Edit:
Code: 
[strand.221] $ freebsd-version -kru
13.2-RELEASE-p3
13.2-RELEASE-p3
13.2-RELEASE-p3
[strand.222] $ pkg -vv | grep url
    url             : "http://pkg0.bbt.freebsd.org/FreeBSD:13:amd64/latest",
 
sremick said:
I don't pay super-close attention the long lists I'm presented each time where pkg tells me what will get upgraded, what will get re-installed, and will get removed
Click to expand...
So some people here will learn to pay attention when a "Number of packages to be removed" arises, and will learn to read whether it is something they need - or just random libraries (and whoever administrates a server should always read the long list closely). IMO that's basic when going with packages on every (!) OS where packages have dependencies, and nothing to blame (f.e. you've got the same on every system with the praised Debian packages).
 
jmos said:
So some people here will learn to pay attention when a "Number of packages to be removed" arises, and will learn to read whether it is something they need - or just random libraries (and whoever administrates a server should always read the long list closely). IMO that's basic when going with packages on every (!) OS where packages have dependencies, and nothing to blame (f.e. you've got the same on every system with the praised Debian packages).
Click to expand...
That's rather glib. Sure one can try and be dismissive with "well guess you should've read the screen!" but I'm going to once again counter that:
  1. It is not intuitive behavior for "pkg upgrade" (emphasis on the "upgrade") should ever ever uninstall existing working packages (I don't care what is tossed onto the screen).
  2. An internal build server having problems building a new version of a package is not a justifiable reason to go about and uninstall the existing, working version of the package already installed on users' computers.
So far I have no seen responses to those two points. It's been a hot mess of people either misunderstanding what's being claimed, or simply dismissing what multiple people have seen with their own eyes as "impossible.
 
You can repeat that as long as you want to, but it won't change anything: That on a system with package dependencies sometimes packages are uninstalled even during a simple update is simply logical and indispensable in such a system.

There is no "give me a solution / response"; That's simply one disadvantage of not shipping everything a software needs in one package. It is a basic design decision of how packages work (which AFAIK all unixoid operating systems with packages decided that way - for good reasons).

Complains about that behavior will lead to nothing.

And: A packages isn't deinstalled because a build server failed to build it, but because a dependency of the old package isn't met anymore when doing an update of the other ones; If a package isn't available anymore you will have it installed as long as it dependencies are met.

The solution is simply to wait for the update till your package dependencies are met again.
 
jmos said:
Complains about that behavior will lead to nothing.
Click to expand...
I don't believe that's in any way inevitable.

I agree with sremick that the behaviour of "pkg upgrade" in removing a working package is counter intuitive, and I think that there are very good reasons to change the way that pkg behaves. It has surprised and inconvenienced a lot of people.

I understand the technical difficulties. If nothing else, it could advertise its intent more aggressively, and require specific confirmation.
 
cracauer@ said:
I wonder how e.g. Debian deals with this. Surely they will bomb out on dependencies, too.
Click to expand...
AFAIR, it's pretty much the same on their "unstable" (aka "sid") distribution. They keep the older package in the repository, but that's just a detail, because of course you'll run into broken dependencies trying to upgrade, with apt suggesting to remove packages to solve the situation. If ever possible, several different suggestions will be made (which is kind of nice, you can accept the solution that's most "acceptable" to you), but anyways, you'll end up uninstalling something or abandoning the whole upgrade.

What they do on their "stable" dist to avoid this kind of issue is: Never ever upgrade any software, instead the maintainers backport required fixes. This of course works, but comes with other (security!) risks, and we've seen that in practice.

This whole thread turned into ridiculous nagging about the way FreeBSD (pkg) deals with an issue that's impossible to solve at the distribution level. Every distribution has to deal with it in some way, and if you don't like FreeBSD's approach, well, use something else.

Comparisons with Windows are especially silly because there just isn't any (official) software distribution on Windows, instead you're all on your own installing and maintaining individual software.

A more recent trend is to package "everything but the kitchen sink" for each software package ... like with MSIX packages on Windows, or stuff like "flatpak" or "appimage" on Linux. Sure, this will also solve the issue of broken dependencies. The price is, you'll have the same crap (mostly "shared" libs) installed a dozen of times, most likely in different versions, and you'll certainly have some old and vulnerable versions among them with no reliable way to ever know about it. That's a trade-off I personally don't want.
 
Again, some people are confused. Someone here claims there was a working copy of libreoffice on their system and, when they did pkg upgrade, it removed libreoffice and left them hanging. (or removed some other software and left them hanging.) None of that has happened, that's not what started this thread, but this thread is running off the rails as if it did.
 
  • Like
Reactions: mer
About the only "improvements" I see based on the output shown in #82 is flip the order of upgraded/removed/reinstalled and maybe under "Number removed" put the list and maybe change the Proceed prompt if anything is going to be removed to something like "Proceed with this action INCLUDING THE REMOVAL OF INSTALLED PACKAGES [yN]"

But as folks have been trying to point out, by default the pkg command, as long as you don't run it with "-y" or "-f", there is ample warning and user interaction required to actually do anything.

To the best of my recollection, the pkg command has been this way since day one (or almost day one). I personally do not want it get to "packages are going to be removed, proceed nY are you sure nY are you really really sure nY"

"Someone here claims there was a working copy of libreoffice on their system and, when they did pkg upgrade, it removed libreoffice and left them hanging."

The user remove the working copy when they said "Yes, proceed" to the pkg upgrade command; which the default (just hit return) is "No, don't do anything". So a decision by a user to say "Go ahead".

I think automatically saying Yes is trained by the design of a lot of modern software. Too many dialog boxes pop up, "Are you sure Y/N" people have been trained to just click Yes.
 
sremick said:
An internal build server having problems building a new version of a package is not a justifiable reason to go about and uninstall the existing, working version of the package already installed on users' computers.
Click to expand...
gpw928 said:
I agree with sremick that the behaviour of "pkg upgrade" in removing a working package is counter intuitive, and I think that there are very good reasons to change the way that pkg behaves.
Click to expand...
The cause why pkg(8) is asking to remove libreoffice is because of its library dependencies
gpw928 said:
Code: 
Installed packages to be UPGRADED:
...
boost-libs: 1.82.0_1 -> 1.83.0
...
libcmis: 0.5.2_8 -> 0.5.2_9
...
liborcus: 0.17.2_4 -> 0.18.1
...
Click to expand...
2., 22., 7. on the list, which are intended to be upgraded. Those library upgrades won't be compatible with the old libreoffice version, most likely break completely or partialy the functionality of it.

Now, what shall be done? Leave a brocken (or diminished in function) version of a package installed or removed after consent? I emphasize here after consent.
 
PMc said:
The issue isn't discussed. The issue is that libreoffice fails to build, and I don't see a word here about how to fix that.
Click to expand...
forums.FreeBSD.org

editors/libreoffice disappeared from ports

Interesting. It's missing from the ports tee but I can't find any recent ports fallout information about it: https://portsfallout.com/fallout?port=editors%2Flibreoffice%24 Maybe I'm missing something. There was a new commit for it today though.
forums.FreeBSD.org forums.FreeBSD.org

On the other hand, it is a misconception.
pkg does not update applications, but rather packages and dependencies. You can't compare an app store with low-level tools. The free software development model has been explained quite well here.
I understand the complaints but I don't share it. I also wouldn't use the latest branch if I'm not willing to encounter these types of bugs.

In my early days with Debian I dealt with updates that removed the entire KDE environment, Xfce applications that didn't go into the stable release, sane backends with bugs that forced me to use the oldstable branch throughout the lifecycle, firmware compilation on every kernel update. It's free software things.
 
CuatroTorres said:
They are free software things.
Click to expand...
No. While I agree with the rest of your post, this claim is not true. Integrating individually developed components to form a working system is a very generic issue always present in software development, it's hitting commercial/propriatery software and in-house developed software just the same. There's no (sane) way to ever develop everything you need from scratch, therefore using 3rd party modules, libraries, etc is unavoidable. And whenever there is some "breaking change" in some API (or ABI), there will be issues.

The (IMHO) best way to address these problems is to actually THINK about your interfaces, plan them to be flexible enough to rarely requiring breaking changes, apply some sane (semantic) versioning for cases when they nevertheless do and make sure that in such a case, several "major" versions can coexist on the same machine for some time. Of course, these are all things that can't be done on the distribution level, that's too late.

This "let's deploy anything including ALL dependencies with some isolation magic" approach taken by "appimage" and co (and in some sense, docker is a similar idea, although going even further) is an attempt to solve the issue on the distribution level. It's a very heavyweight solution, and also one creating new problems. Just as an example, there are already security tools just for the purpose of scanning some software project (the source!) with ALL dependencies (that will be deployed together with that project) for known security issues, so you can react by updating the problematic dependency and carry out a new deployment. To me, this is all backwards, really.
 
And as of a few minutes ago, editors/libreoffice is now back as a package and can be installed. The original point of this--and the more current other--thread has been solved and we can move on.
 
mer said:
To the best of my recollection, the pkg command has been this way since day one (or almost day one). I personally do not want it get to "packages are going to be removed, proceed nY are you sure nY are you really really sure nY"
meone here claims there was a working copy of libreoffice on their system and, when they did pkg upgrade, it removed libreoffice and left them hanging."

The user remove the working copy when they said "Yes, proceed" to the pkg upgrade command; which the default (just hit return) is "No, don't do anything". So a decision by a user to say "Go ahead".

I think automatically saying Yes is trained by the design of a lot of modern software. Too many dialog boxes pop up, "Are you sure Y/N" people have been trained to just click Yes.
Click to expand...
The more you make things idiot-proof, the more you train people to become idiots.

T-Daemon said:
The cause why pkg(8) is asking to remove libreoffice is because of its library dependencies

2., 22., 7. on the list, which are intended to be upgraded. Those library upgrades won't be compatible with the old libreoffice version, most likely break completely or partialy the functionality of it.

Now, what shall be done? Leave a brocken (or diminished in function) version of a package installed or removed after consent? I emphasize here after consent.
Click to expand...
Thank You.

Whenever pkg states it will remove something, this should be read as a warning message. You didn't know that? So now you have learned it for free: nothing bad has happened. No data was lost. You can reinstall a proper libreoffice at any time.

CuatroTorres said:
forums.FreeBSD.org

editors/libreoffice disappeared from ports

Interesting. It's missing from the ports tee but I can't find any recent ports fallout information about it: https://portsfallout.com/fallout?port=editors%2Flibreoffice%24 Maybe I'm missing something. There was a new commit for it today though.
forums.FreeBSD.org forums.FreeBSD.org
Click to expand...
But that's not to the point. The point is that libreoffice has a defect of randomly failing the build. And apparently it has this defect for more than a year already, and then people start to complain here (about their personal comfort zone being violated, that is), but nobody bothers to identify and fix the defect.
 
  • Like
Reactions: mer
gpw928 said:
Installed packages to be REMOVED:
libreoffice: 7.5.5.2_3

Installed packages to be UPGRADED:
assimp: 5.2.5 -> 5.3.1
boost-libs: 1.82.0_1 -> 1.83.0
Click to expand...

OK, assuming this is caused by the boost update.

How much confirmation has there been that the old (buildable) libreoffice actually doesn't work with boost 1.83?

A quick look at /usr/local/lib reveals that the filename changed, the 82 version number was encoded in it: libboost_date_time.so.1.82 etc. So if libreoffice was linked directly against that it is guaranteed to fail.

If you were hacking it up there would be no reason you couldn't have left the libboost_*.so.1.82 etc. installed while libboost_*.so.1.83 is also installed. You could achieve that by just running ./confgure && make install on the two source trees. This is not done in the ports tree because the old library version might need support files that are not shared libs, which would clash between the versions.

Now, what you could do is build the old (buildable) version of libreoffice against boost 1.83. There is a chance that this fails, but not a big one. A minor version change should not break source building.

This now goes back to the question of why exactly libreoffice failed to build. Was it a bad new version of libreoffice or did some dependency update make it fail although we are still on the old (previously buildable) version of libreoffice.
 
Could you fix it by placing an easy softlink in /usr/local/lib & pretending the correct "libreoffice version" of libboost was installed ?
 
In other words, the problem here is that on build failure of a certain package in the new tree there is no attempt to build the old version of that certain package from source. The old binary version is guaranteed to fail, and since that is the only thing on offer th package can as well be removed. But we don't know whether a new source build of the old version would have been successful.
 
You must log in or register to reply here.
Back
Top