Port upgrading, a bad experience

[mnd999]

Hi all,

Since I reinstalled with FreeBSD 10, I've been trying to get away from building ports, and just use pkg but today's was not good. In order that others can learn from it (and possibly documentation can be improved) I'll share.

* I went to upgrade with pkg but this failed giving my a long list of conflicting files, mostly around DocBook. Okay, I thought I'll portsnap fetch update and read /usr/ports/UPDATING. That indicated that DocBook had been upgraded and I needed to delete the old version manually (why?).

* Reading further down I also saw that KDE had been upgraded and I needed to now use the WITH_NEW_XORG option and follow some instructions on the graphics wiki to update Xorg. I think this was my first mistake.

* I followed said instructions, which caused me to install portmaster and rebuild some X ports.

* I then ran pkg update which failed again. This time failing with conflicts on some IM library (I don't recall) required by kopete. I figured that since KDE was getting upgraded anyway I might as well just delete it. Not sure why I had to do this manually.

* I then ran pkg upgrade successfully, all good I thought and as per the instructions in UPDATING, cleaned up the remaining files in /usr/local/kde4. Second mistake.

* On rebooting, X failed to start, which I incorrectly put down to a the new Xorg not working. I soon realised though that pkg had not upgraded all of KDE4, just some (or none?) of it and I now had a bit of a mess to fix.

* I ran portmaster -ayPD to attempt to install the KDE upgrade manually and fix the mess. I guessed the appropriate responses to the options dialogs and the build proceeded until kde4-workspace where it bombed out with a linker error. After some more investigation, I was able to get kdeworkspace to build by turning of the OpenGL ES2 option which doesn't work (or at least not on my Nvidia system).

* Reran portmaster, it decided to rebuild libreoffice which takes a long long time but I'm not going to argue with it because I don't want to make things worse. Hopefully all should be good now.

This was not a good experience and whilst I'm pretty sure I made some mistakes, the 'simple' pkg tool did not work well here and the documentation in UPDATING was at best misleading for those not building ports.


Mark

 

[wblock@]

If you need anything not built into the binary packages, it's generally a good time to stop trying to use the binary packages. The KMS graphics drivers are a good example. Build those from ports, and they work fine. And in fact, that is the only way to get them.

Then start trying to update with binary packages built on another system. This is the major problem with binary packages, they are built with certain assumptions, and if any of those assumptions are not correct on the target system, problems begin. In general, don't mix the two systems. If you need to build anything from ports, stick with ports.

That also includes /usr/ports/UPDATING. As far as I know, users of pre-built binary packages can ignore it, it only applies to ports.

 

[ShelLuser]

I think there's one basic aspect where you went wrong:

This was not a good experience and whilst I'm pretty sure I made some mistakes, the 'simple' pkg tool did not work well here and the documentation in UPDATING was at best misleading for those not building ports.

But that's just the thing; if you're not building your own ports then you have no business with /usr/ports what so ever. And to be honest I think that is made clear in several parts of the documentation. For starters the UPDATING file itself: "You should get into the habit of checking this file for changes each time you update your ports collection, before attempting any port upgrades.".

But also the FreeBSD handbook; chapter 5 shows you that there are 2 options to install software: using pkgng for binary package management and using the Ports collection.

If you go over the section which explains pkgng you'll notice that it doesn't mention /usr/ports/UPDATING anywhere. However if you go over the next section, which explains the "Ports collection method", then you will come across this file.

Now, don't get me wrong here; my intent here is not to go "it should have been obvious" because I've been here myself as well. It's fully true that in some cases the sting is in the details; and if you overlook those details you can (and will!) make mistakes which, when looking back (that is always easy!), seem just way too obvious.

But I also think it's fair to say that the whole thing has been documented

Still; in the end I agree with you about pkgng, especially for binary packages. I had my laptop running on FreeBSD 9.2 and all software directly installed from the previous (pkg_*) repositories and getting myself a working KDE4 environment was peanuts. With FreeBSD 10 I can't cope with this for the simple reason that KDE4 isn't available as of yet.

So yeah; although I think the new tools are indeed very impressive when it comes to package management I'm a little disappointed in the current state of the repository as well. It's hardly usable in my opinion if you want more than a good dose of commandline utilities.

For example; I have a virtual FreeBSD 10 environment (using VirtualBox) on which I build everything from source. The base OS and all the ports; right now it runs Xorg together with Xfce4, SeaMonkey, LibreOffice and a few games. I then installed the whole lot on my laptop using merely pkgng and although I somewhat got the same results the experience is pretty different. Items are missing in my menus, some programs don't even show up at all, and in the end it feels as if Xfce4 isn't even working in the way it should be.

So yeah, until they've fixed all that I think your best option with FreeBSD 10 (basically with pkgng) is to use the Ports collection yourself.

 

[mnd999]

I want to come back on some of this, because whilst I wasn't doing everything 'by the book' I think my actions were reasonable given the broken state I found myself with.

If you go over the section which explains pkgng you'll notice that it doesn't mention /usr/ports/UPDATING anywhere. However if you go over the next section, which explains the "Ports collection method", then you will come across this file.

Yes but I can (and in this case was forced to) do this:

[mark@markspc ~]$ pkg updating docbook
20140219:
  AFFECTS: users of textproc/docbook*
  AUTHOR: mat@FreeBSD.org
  pkg users can run:
    pkg delete -f docbook-xml\* docbook-sk\* docbook\[2345\]\?\?-\* docbook-4\*

Seeing as the pkg tool builds in support for /usr/ports/UPDATING, I think it's reasonable to assume that the information contained in it is relevant. Without it's use as far as I can tell the DocBook upgrade will break everything. My mistake was assuming that since this file was relevant to what I was doing with DocBook it was also relevant to KDE. I think that was a reasonable assumption to make.

Mark

 

[ShelLuser]

Seeing as the pkg tool builds in support for /usr/ports/UPDATING, I think it's reasonable to assume that the information contained in it is relevant. Without it's use as far as I can tell the docbook upgrade will break everything. My mistake was assuming that since this file was relevant to what I was doing with docbook it was also relevant to KDE. I think that was a reasonable assumption to make.

Now that is a pretty solid argument in my opinion. Even though I knew this option existed I totally forgot all about it.

And I think it's even worse.

I just grabbed my laptop (which, as mentioned earlier, only contains binary packages) and what do you know?

feliner:/home/peter $ pkg updating | wc -l
    1138

I just went over pkg-updating(8) myself and there's no mentioning anywhere in which way the information you get here is (or isn't) relevant to your environment.

I'm tempted to consider this a recipe for disaster, even though that could be a bit drastic. But yeah; I can see that this is very likely to confuse quite a few people. In my opinion this warrants a PR, at the very least to request the addition of some extra information in the manual page.