How to upgrade a port to the next version?

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.
Click to expand...
It costs some resources (and time), no argument there, but unneeded? I beg to differ.

Because you're now also assuming that an upgrade will always go flawlessly. It usually does; but I have had situations where a port acted up during the installation phase. Meaning: the old version had been removed and the new version refused to install. Now what?

Well, thanks to the package system (and portmaster) I could simply look into /usr/ports/packages and re-install the previous version. Resulting in minimal downtime.

There's more to the package manager than mere cosmetics ;)

Chris_H said:
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...
But what choices did they have with the old package system? They could either use it, or not. Well, not entirely of course, but as you mentioned yourself: it's not as if you could use the ports collection without the package manager in the first place.

And well, I also think that your comment doesn't do much credit to the way the developers behind pkgng have made sure that the changes are kept to a minimum. I mean, some things may look easy enough, but that's only because it's already there.

Personally I think the approach of replacing pkg_info with pkg info is a very clever design. So in your example; depending on how people were using the old package manager, all they need to do is replace an underscore with a space (this is assuming front-end tools of course).

I've postponed the upgrade for a long time, waited until two months ago I think, but so far I've had no issues with pkg.
 
kpa said:
You are not supposed to know what the internal implementation of the PKG database is.
Click to expand...
I wouldn't go as far as stating that you're not supposed to know. That almost sounds binary-blob-ish. You may have meant to say that the internal database implementation is supposed to be transparent to the end user, which is usually good practice.
 
ShelLuser said:
And well, I also think that your comment doesn't do much credit to the way the developers behind pkgng have made sure that the changes are kept to a minimum.
Click to expand...
Hmm. Recent changes to pkg have broken Tinderbox, which in turn is what (among other things) drivers Redports, of which it is in turn appreciated if you include build logs in ports-related PRs.

Breaking such an important tool just for the sake of pushing something new doesn't sound like sound software engineering practice to me. I don't remember off the top of my head whether it was in this thread or another one, but I did mention an analogy along the lines of someone blindly swinging an axe around. As good as the intentions may be, the amount of concern for collateral damage leaves something to be desired IMHO.
 
wblock@ said:
Tinderbox has been at least partially supplanted by ports-mgmt/poudriere.
Click to expand...
Poudriere does more than Tinderbox, maybe in some cases more than people want. Moreover, the way Poudriere sets up and manages its jails remains entirely undocumented and trying to reverse-engineer what it does is a royal PITA. Furthermore, as far as I know there has been absolutely no prior warning whatsoever that Tinderbox would be broken and everybody would be forced to switch to Poudriere.
 
fonz said:
Hmm. Recent changes to pkg have broken Tinderbox, which in turn is what (among other things) drivers Redports, of which it is in turn appreciated if you include build logs in ports-related PRs.

Breaking such an important tool just for the sake of pushing something new doesn't sound like sound software engineering practice to me.
Click to expand...
Well, first off: since I'm not using Tinderbox myself I'm not fully familiar with the whole situation. However, with situations like that I can't help wonder if the port should 'follow' the development cycle/changes in the main package manager or if the package manager should try to keep up with third party software which is being used.

If we're talking about suddenly changing commandline parameters "because" then I can well understand the issue. But if you're referring to changes which caused issues because Tinderbox used internal parts of the pkg system, then it would become a different issue for me.
 
Last edited:
ShelLuser said:
However, with situations like that I can't can't help wonder if the port should 'follow' the development cycle/changes in the main package manager or if the package manager should try to keep up with third party software which is being used.
Click to expand...
It's a bit of both IMO. I'd call Tinderbox second-party rather than third-party. It's FreeBSD-specific and is (or was) an important part of the ports infrastructure, not just somebody's pet project. With that in mind, I'm inclined to think that pkg ought to have paid more attention to the bridges it burnt while whole cities were still (happily) using those bridges. I can't help but feel that this was a deliberate move to push people towards "use Poudriere or take a hike". Otherwise they would have been way more careful with what they euphemistically call "minor updates".
 
noobster said:
See http://daemonforums.org/showthread.php?t=3711#post26580. I was under that same impression and if you scroll down the conclusion seems to be that the use of pkg_delete was added at some point. I guess my knowledge was somewhat outdated.
Click to expand...

From the SVN commit log of /usr/ports/Mk/bsd.port.mk
Code: 
------------------------------------------------------------------------
r9248 | asami | 1998-01-02 12:37:14 +0200 (Fri, 02 Jan 1998) | 23 lines

About one month worth of bsd.port.mk improvements.

(1) Allow multiple checksums of same file.
Submitted by:   hoek

(2) Add "deinstall" target as an alias to "pkg_delete $(make package-name)"
    (well, something like that, see diff for details).
...

That's over 16 years ago now :rolleyes:
 
POLA!

For all that [the new] pkg(8) professed to cure, and all the dreams it would fulfill, pkg has easily caused an equal amount of nightmares. Honestly, [the new] pkg(8) does make some things easier... well, simpler, and I would have no gripes about it. If it weren't for the fact that it replaced the old pkg(7) system. It was forced upon us, before it was actually capable of replacing it (assuming it's a fully suitable replacement). I'm really quite angry about the sqlite3(1) requirement. It is a single point of failure. Which is bad practice for any critical -- see BASE software. I never had trouble with pkg(7)'s largely text based record keeping system, nor portmaster(8). I can't say the same for pkg(8). It appears to have corrupted (or just blown away) my local database. I believe nightly cron(8) makes a backup by default. But how to recover? the man(1) pages for pkg(8) make no mention of it. poo-dree-air would/could be god's gift to mankind, save there's no concise documentation -- can you hear me, wblock@? :). The man(1) pages have a near-overwhelming amount of information. But context can easily become lost trying to read it, because of all the data. I wish I had a box (and the time) to just play with it, and try to figure it all out. But at present, all that's available is "I did poudriere this way to do this" kind of documentation. That's all well, and good. But without reading every-single-one available. It will be very difficult to get a good grasp for executing the best method for getting the desired task done. I currently maintain some 23 ports. I think it would be handy to ask poudriere to build all my tests, log the results. So I can take on other tasks, and be more productive. It'd be nice to ask it to build the world, kernel, and selected ports, for the some 60 servers I maintain. But I find the documentation, and examples available, fall a bit short. Even though there are a number of them that explain their experience doing nearly that. But I digress...

fonz said:
I don't remember off the top of my head whether it was in this thread or another one, but I did mention an analogy along the lines of someone blindly swinging an axe around. As good as the intentions may be, the amount of concern for collateral damage leaves something to be desired IMHO.
Click to expand...
Yes. It was this thread -- about third reply, as I recall. Good analogy, BTW. :)

--Chris
 
"How to upgrade a port to the next version" -- in another thread which has no replies so far AFAIK -- I upgraded pkg-devel in a "newbie" fashion, having had failures with a straight upgrade in the past. Thereupon, the new version worked better, as its commit text hinted it would, despite something to the effect that the sqlite database version was too new but still compatible.

Subsequently, I found that ports would no longer register with a serious pkg-static five-line error. I restored the previous pkg-static from yesterday, and it is working again, but seems here to be missing a key feature, like an upstream installable package that can overwrite the ports pkg and libraries, and a tool somewhat like make delete-old-libs that can examine every pkg related file in the system and suggest keeping, removal, from base and not needed, from ports and obsolete, mismatched version, incompatibility between base library and port library, and a host of other issues that may arise. Just for reliability's sake (I formulated this idea from repeatedly installing the chromium port only to have it segfault and not start week after week, maybe a working chromium wrapper that performs similarly would be a feather in FreeBSD's cap to post in threads making it more of a viable alternative for those using Windows or Linux).

I can probably do some of the above here on a spare machine, but it is going to take time and only cover the most basic issues for a debugging checklist I could maybe use to help with pkg failures to come since I am used to readily installing the -devel versions whatever the cost in reliability, sometimes with unwanted effects.
 
Last edited by a moderator:
Chris_H said:
I'm really quite angry about the sqlite3(1) requirement. It is a single point of failure. Which is bad practice for any critical -- see; BASE, software. I never had trouble with pkg(7)'s largely text based record keeping system,
Click to expand...

Then you were lucky. Many of us had trouble with blank lines in the dependency files. That's not a problem any more.

nor portmaster(8).
Click to expand...

Well, good, but that has nothing to do with pkg(). portmaster just uses whatever package management system is present.

poo-dree-aye would/could be gods gift to mankind, save there's no concise documentation -- can you hear me, wblock@? :).
Click to expand...

I hear you. Have you read the Handbook section? Have a look at who edited and committed (but did not write) that. After working on documentation that people needed, but for things I did not use myself, I learned that it was better for me to avoid that. Things I use can be tested and verified. There are many things that others use which badly need improved documentation, like freebsd-update(8). For some reason, the people who use "easy" and "fast" update tools rarely contribute to documentation.

I currently maintain some 23 ports. I think it would be handy to ask poudriere to build all my tests, log the results. So I can take on other tasks, and be more productive. It'd be nice to ask it to build the world, kernel, and selected ports, for the some 60 servers I maintain. But I find the documentation, and examples available fall a bit short. Even tho there are a number of them that explain their experience doing nearly that.
Click to expand...

mat@ has done a lot of work on the Porter's Handbook lately, and has a huge update that describes using Poudriere for port maintainers. I've reviewed about half of the thousand lines of source for it, and it is likely to be committed in the next week or so.
 
Well, as I'm hardly ever using packages I'm possibly missing some trouble created by changing from pkg_ to pkg.

Concerning the decision to change the database from a file based implementation to sqlite, however, I do not see any problems or basis for hefty criticism. What should the developers do? Just leave it the way it was? No. For diverse reasons, some of them safety related, some of them performance related. Do not forget that opening files is an expensive operation you wouldn't like to do hundreds or even thousands of times without urgent need.

Use a database but not an SQL based one? No. For diverse reasons, one being that using SQL many tools can use the database without replicating internals (as one would have needed to do with, say *gdb); that would quickly turn into a nightmare when needing to change the slightest detail. And SQL offers other advantages, too, for a rather modest price (after all, ports/package management isn't a 24/7/365 running task with many clients).

I've written a ports tool myself and I'm quite happy with the sqlite decision. In case some detail needs to be changed or added with the database, my code (and that of all other tools) will continue to work.

Now, if it's true (again, I don't know because I don't use packages) that they broke consistency and compatibility then that's a sin, yes, and an ugly one for that. Reading discussions on that matter I wonder why the pkg(ng) developers didn't create a compatibility version of the pkg_ tools? Some (quite simple?) script replacements that would simply call the new version, at least for the major and mainly used pkg_ commands.
 
Well, if your database breaks, or cannot be updated, or is corrupt, or internally inconsistent, one is more likely to have to email upstream than write a simple shell script or patch, a situation I had for a few hours yesterday, for which I see no reason not to rework the legacy package database and have it optional again, even with a new command such as install-textwise. Maybe some ports installed with one packager, some with another, the problem here is that it is just a concept and requires a lot of work to implement. It's not urgent here, but for other users I suspect it really is; in fact I have more hours freed up under the new packaging system.
 
wblock@ said:
Then you were lucky. Many of us had trouble with blank lines in the dependency files. Not a problem any more.

Well, good, but that has nothing to do with pkg(). portmaster just uses whatever package management system is present.
Click to expand...

chris_h said:
I digress...
Click to expand...

True. :)

wblock@ said:
I hear you. Have you read the Handbook section? Have a look at who edited and committed (but did not write) that. After working on documentation that people needed, but for things I did not use myself, I learned that it was better for me to avoid that. Things I use can be tested and verified. There are many things that others use which badly need improved documentation, like freebsd-update(8). For some reason, the people who use "easy" and "fast" update tools rarely contribute to documentation.

mat@ has done a lot of work on the Porter's Handbook lately, and has a huge update that describes using Poudriere for port maintainers. I've reviewed about half of the thousand lines of source for it, and it is likely to be committed in the next week or so.
Click to expand...

That's welcome news. I haven't checked for a couple of weeks. I'm speaking from about three weeks ago, regarding a conversation I had with John (marino@) on the subject, while attempting to provide better QA for some of the ports I was responsible for. If things have changed in that regard since then, then I take that back -- I'll have another look. :)

Thank you very much for the thoughtful, and informative reply,
wblock@.

--Chris

P.S. wblock@, Thank you very much for all your hard work on docs@!
 
AzaShog said:
Speaking of which... where in the superb FreeBSD documentation / manual is this documented? I'm trying to google for it, but can't find it...
Click to expand...
You can grep(1) for it in the ports/Mk/ files. Sorry. I can't remember which one, off the top of my head. :p

--Chris

EDIT: DEFAULT_VERSIONS, that is.
 
You must log in or register to reply here.
Back
Top