How to upgrade a port to the next version?

Chris_H

Chris_H

Greetings,

I've been using portmaster(8) as my standard upgrade path. But since the advent of pkg(8) nothing is easy anymore. I don't want to use packages, because I have no control of their contents, and they have no consideration for my options.

That said, I'm looking to upgrade lang/php53 to lang/php55. I had hoped portmaster -n php would do it (I chose -n to insure it was going to DWIM). But it indicated that all it was going to perform, was to re-install php53. I also tried portmaster -o lang/php55 php53. But it just said that everything is already up to date.

Ugh... Anyone have some insight they'd be willing to share?

Thank you for all your time, and consideration.

--Chris

P.S. This is on RELENG_9.
 
Code: 
sudo portsnap fetch update
cd /usr/ports/lang/php55
sudo make config
sudo make install clean

This will install php55 to your system. Now you can remove php53.
 
I seem to remember having seen something in /usr/ports/UPDATING about DEFAULT_VERSIONS or something along those lines. Have you tried that? I'm not very picky about my exact PHP version so I haven't experienced your problem personally, sorry.
 
OK, the quote link is broken. So I'll have to do this manually, fonz.

I currently don't have lang/php listed in the DEFAULT_VERSIONS stanza. I added it, citing php5.5. But to no avail. Same problem.

I guess I'm stuck performing this brutally, and just ripping 53 out by the roots, and installing 55, hoping there won't be any issues with the symbols in the libraries. :(

Thank you very much for taking the time to respond, fonz.

--Chris
 
Chris_H said:
OK, the quote link is broken.
Click to expand...
That's probably a misunderstanding due to having to get used to the new forum software. The +Quote button merely toggles multi-quote. What you were probably looking for is the Reply button, which quotes automagically [sic]. Maybe we should rename those links.
 
obsigna said:
There is a missing path component in above command. The correct command would be: portmaster -o lang/php55 lang/php53
Click to expand...
Thanks for the reply, obsigna. Sadly, this was what was returned:
Code: 
# portmaster -o lang/php55 lang/php53

===>>> Gathering dependency list for lang/php55 from ports
===>>> Initial dependency check complete for lang/php55


===>>> Starting build for lang/php55 <<<===

===>>> All dependencies are up to date

Not quite what I had hoped for -- and yes, pkg info | grep php, does indicate php5.3. :p

Thanks again, obsigna.

--Chris
 
fonz said:
That's probably a misunderstanding due to having to get used to the new forum software. The +Quote button merely toggles multi-quote. What you were probably looking for is the Reply button, which quotes automagically [sic]. Maybe we should rename those links.
Click to expand...
Right you are, fonz!

I guess I'm too wrapped up in my issue to be more astute (clever enough to figure it out, myself). :rolleyes:

Thanks, fonz!

--Chris
 
Chris_H said:
Thanks for the reply, obsigna. Sadly, this was what was returned:
Code: 
# portmaster -o lang/php55 lang/php53

===>>> Gathering dependency list for lang/php55 from ports
===>>> Initial dependency check complete for lang/php55


===>>> Starting build for lang/php55 <<<===

===>>> All dependencies are up to date

Not quite what I had hoped for -- and yes, pkg info | grep php, does indicate php5.3. :p

Thanks again, obsigna.

--Chris
Click to expand...

OK. I forgot I had used the -n switch. Re-running the command without it caused php53 to be upgraded to lang/php55. BUT this resulted in my having to manually upgrade 50 PHP extensions. :(

I was also forced to do the process forcefully (deinstall), then make install the php55 version(s). this ran into other libraries complaining about already being installed. :( Let the symbol clashes begin! <grrr>

Thus far, I would estimate that pkg(8) has cost me some $7,000.00 US. It's also cost others -- some, even their jobs! I'm not a happy camper, right now. :(

Thank you for all your thoughtful suggestions. I do appreciate them. In spite of feelings regarding pkg(8).

--Chris
 
This is nothing to do with pkg(). After upgrading that port, it is normal to upgrade the ports that depend on it. Look at the 20141008 entry for Ruby. It does the same thing.
 
Chris_H said:
Thus far, I would estimate that pkg(8) has cost me some $7,000.00 US. It's also cost others -- some, even their jobs!
Click to expand...
Granted, pkg has broken a thing or two here and there (including Tinderbox, which drives Redports, the logs of which in turn are/were appreciated in PRs). And the initial impression might be that of someone blindly swinging an axe around (and we probably both know who's wielding said axe). However, on the other hand there are many problems attributed to pkg that aren't actually pkg's fault. Just saying...
 
fonz said:
Granted, pkg has broken a thing or two here and there (including Tinderbox, which drives Redports, the logs of which in turn are/were appreciated in PRs). And the initial impression might be that of someone blindly swinging an axe around (and we probably both know who's wielding said axe). However, on the other hand there are many problems attributed to pkg that aren't actually pkg's fault. Just saying...
Click to expand...
Fair enough. pkg(8) does make some tasks easier. But I'm afraid that the work of many people, consisting of many years, developing toolchains to simplify, and make upgrade tasks like th(is|ese) are no longer as dependable, if they still work at all. And yes, pkg(8) is easy to blame for things that it's not directly responsible for. But it does get in the way, and must be worked around. So I guess what I'm trying to say; is it's not doing anyone any favors, if one has to overcome new challenges to solve problems that already had working solutions. Even worse, when you discover the "new challenge" after the damage has already been done. :(

Thanks to you both, fonz and wblock@!

--Chris
 
I love the new pkg. All the ports I need with different options just get built using poudriere, and then I am a happy camper. Actually being able to replace the whole version of, say php53 to php55, in one step is fantastic.
 
[ Maybe the preferences I've set in the new forums have broken posting private messages... ]

I'd have no problem with pkg_info etc. backported to be useful again, in the latest FreeBSD versions, where one could use pkg OR /var/db/pkg/ (Portmaster legacy) or, better yet, /var/db/pkg integrated as a frontend, backend, option, port, redundancy check, etc. for those more at ease with pipes than SQL (not wishing to disparage the latter). So the costs mentioned above incurred by the improvements could be minimalized (also at a cost). Even if such a thing were subscription-based as a port, or as simple as a few added pkg tools, somewhat of a mini-poudriere-builtin. I'm not familiar with the latter enough to expound more.
 
I guess it comes down to this; FreeBSD was all about choices, but pkg(8) removed many of those that people had relied upon. IMHO it shouldn't have been a matter of "This way, or the highway". pkg(8) should have been an additional option, or at least been put up to "vote".

As to pipe(2) v SQL; I find pipe(2)'s a great deal faster for upgrade paths. It also lowers the bar for those less inclined, where SQL is concerned.

Thanks for your replies.

--Chris
 
What choices did pkg(8) remove? It's a drop-in replacement for the old package system. Some of the commands are a little different, but not much. The database is SQLite rather than text files, but they can still be manipulated directly. The worst problem has been the perception that it's a replacement for ports. It is not, it's just the package management system.
 
wblock@ said:
What choices did pkg(8) remove? It's a drop-in replacement for the old package system.
Click to expand...
Really? Have you ever tried to build, and install, a port without pkg(8) 1.38? Good luck. :)
wblock@ said:
Some of the commands are a little different, but not much. The database is SQLite rather than text files, but they can still be manipulated directly. The worst problem has been the perception that it's a replacement for ports. It is not, it's just the package management system.
Click to expand...
A couple of things: You are required to build a package, whether you need/want one, or not. This results in more (unneeded) disk I/O, and more CPU cycles, not to mention additional time. This is true whether you like or dislike the new pkg(8). Oh. Did I mention it requires more time and effort to craft the code for the ports themselves? ;)

If someone has spent years crafting a system to work with the old [pkg] tools/system, to finely tune it to their needs, how has the new pkg(8) not removed their choices?

Finally, if you've built a toolset to work with the old system, making use of the text based records, you have the additional step(s) of dumping and converting the sqlite3(1) tables into a form at least similar to the one produced previously. If you're not SQL savvy, you're up a creek.

Thanks for the reply, wblock@.

--Chris
 
The old pkg_* commands were also used when a port was installed. In fact, I thought the old package system also built a package before installing it, although it was not saved.

I can sympathize with having old custom tools to work with the old text file database, I had one bug-fixing script myself. But pkg(8) does not have that bug, because it uses a real database. As a package management system, it can do more and much more quickly than the old system. Yes, if custom package management is needed, it will have to be adapted. One of the costs of progress is loss of backwards compatibility.
 
wblock@ said:
The old pkg_* commands were also used when a port was installed. In fact, I thought the old package system also built a package before installing it, although it was not saved.
Click to expand...

Didn't the old system create packages from installed ports? And the ports themselves did not depend on pkg_*.

Chris_H said:
A couple of things: You are required to build a package, whether you need/want one, or not. This results in more (unneeded) disk I/O, and more CPU cycles, not to mention additional time. This is true whether you like or dislike the new pkg(8). Oh. Did I mention it requires more time and effort to craft the code for the ports themselves? ;)

If someone has spent years crafting a system to work with the old [pkg] tools/system, to finely tune it to their needs, how has the new pkg(8) not removed their choices?
Click to expand...

You would think the additional overhead is minimal compared to the compilation process itself. Also, one package system is replaced by another so there is no reduction in choices but things surely have changed.
 
Chris_H said:
Really? Have you ever tried to build, and install, a port without pkg(8) 1.38? Good luck. :)

A couple of things: You are required to build a package, whether you need/want one, or not. This results in more (unneeded) disk I/O, and more CPU cycles, not to mention additional time. This is true whether you like or dislike the new pkg(8). Oh. Did I mention it requires more time and effort to craft the code for the ports themselves? ;)

If someone has spent years crafting a system to work with the old [pkg] tools/system, to finely tune it to their needs, how has the new pkg(8) not removed their choices?

Finally, if you've built a toolset to work with the old system, making use of the text based records, you have the additional step(s) of dumping and converting the sqlite3(1) tables into a form at least similar to the one produced previously. If you're not SQL savvy, you're up a creek.

Thanks for the reply, wblock@.

--Chris
Click to expand...

You are not supposed to know what the internal implementation of the PKG database is. It happens to be an SQL database now but it might change to something entirely different in future versions of PKG. You're supposed to use the public APIs in your customized scripting, namely pkg-query(8) and related utilities. Your point about having to learn SQL to use PKG is therefore invalid, none should be digging in the internals of the database that is under constant development and can change at any time without any notice. As a proof of what I'm saying, try to find a public API description and the schema descriptions of the PKGNG SQL database that are written for end users. You won't find anything because they have not been written and won't be.

One more thing. The ports system was already quite married with the old packaging tools way before PKGNG because the packaging tools were (and of course still are) the only way register a port as installed and list installed ports. It was possible to install a port without registering it into the package database (with a trick of using the NO_PKG_REGISTER variable if I remember right) but what's the point of that? You wouldn't the see the installed port in the output of pkg_info(8) and you'd have a bunch of untracked files on your hard drive.
 
You're supposed to use the public APIs in your customized scripting, namely
[...]
schema descriptions
[...]
They have not been written and won't be
Click to expand...

I see that as true for most users (such as myself), untrue for some users (such as myself) and as such, an issue of not enough users (and/or coders) using FreeBSD to craft code to make it a moot issue.
 
You can keep shooting yourself in the foot as much as you like by relying on private implementation details such as the PKG SQL database or the insanely fragile and non-robust text database of the old packaging tools. That's your decision. However, IT professionals want good solutions that they can count on and that don't blow up in their face all the time, that's why the old packaging tools were ousted, good riddance.
 
I'm not sure about the exact spot where it's written but it is an official and officially announced fact that packages are basically just pre-compiled ports with default configuration.

I personally have used pkg_ rarely and now use pkg rarely because I build pretty much everything from ports. But I did test play somewhat with PKGNG and I do like it a lot. It feels more convenient in many small details and the fact that a database is now implemented as a database makes perfect sense.

Unfortunately I don't know about portmaster because I happen to be a portupgrade user, but I have not yet encountered an update problem that wasn't easily solvable. Strong hint: Look at UPDATING whenever you portsnap fetch update! Whenever I experienced problems with ports I myself was the guilty party; looking at UPDATING I always quickly found the trouble spot and how to fix it.

Last but not least: I highly value FreeBSD's professional attitude and I'm certain beyond doubt that the FreeBSD developers thought deeply and well before they undertook it to come up with a new pkg system. In my mind's eye they are to be lauded for achieving what they did, namely to create something completely new - and better - yet keeping it (in particular the user interface) very similar to the former system.

And BTW, I upgraded from 8.4 to 10.0 and had no problems in that regard.

(Edit: Small correction)
 
You must log in or register to reply here.
Back
Top