# How to upgrade a port to the next version?



## Chris_H (Oct 17, 2014)

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.


----------



## sk8harddiefast (Oct 17, 2014)

```
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.


----------



## fonz (Oct 17, 2014)

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.


----------



## Chris_H (Oct 18, 2014)

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


----------



## obsigna (Oct 18, 2014)

Chris_H said:


> ... I also tried `portmaster -o lang/php55 php53`. ...



There is a missing path component in above command. The correct command would be: `portmaster -o lang/php55 lang/php53`


----------



## fonz (Oct 18, 2014)

Chris_H said:


> OK, the quote link is broken.


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.


----------



## Chris_H (Oct 18, 2014)

obsigna said:


> There is a missing path component in above command. The correct command would be: `portmaster -o lang/php55 lang/php53`


Thanks for the reply, obsigna. Sadly, this was what was returned:

```
# 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. 

Thanks again, obsigna.

--Chris


----------



## Chris_H (Oct 18, 2014)

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.


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). 

Thanks, fonz!

--Chris


----------



## Chris_H (Oct 18, 2014)

Chris_H said:


> Thanks for the reply, obsigna. Sadly, this was what was returned:
> 
> ```
> # portmaster -o lang/php55 lang/php53
> ...



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


----------



## wblock@ (Oct 18, 2014)

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.


----------



## fonz (Oct 18, 2014)

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!


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...


----------



## Chris_H (Oct 18, 2014)

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...


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


----------



## mix_room (Oct 19, 2014)

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.


----------



## jb_fvwm2 (Oct 19, 2014)

[ 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.


----------



## Chris_H (Oct 19, 2014)

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


----------



## wblock@ (Oct 19, 2014)

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.


----------



## Chris_H (Oct 20, 2014)

wblock@ said:


> What choices did pkg(8) remove?  It's a drop-in replacement for the old package system.


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.


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


----------



## wblock@ (Oct 20, 2014)

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.


----------



## Chris_H (Oct 20, 2014)

wblock@ said:


> One of the costs of progress is loss of backwards compatibility.


*Pro*gress is a matter of opinion. 

Thanks, as always, wblock@. 

--Chris


----------



## noobster (Oct 20, 2014)

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.



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?



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.


----------



## kpa (Oct 20, 2014)

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?
> 
> ...



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.


----------



## jb_fvwm2 (Oct 20, 2014)

> You're supposed to use the public APIs in your customized scripting, namely
> [...]
> schema descriptions
> [...]
> They have not been written and won't be



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.


----------



## kpa (Oct 20, 2014)

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.


----------



## wblock@ (Oct 20, 2014)

noobster said:


> And the ports itself did not depend on pkg_*.



No, it did depend on that.  For example, `make deinstall` just used `pkg_delete`.


----------



## rmoe (Oct 20, 2014)

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)_


----------



## ShelLuser (Oct 20, 2014)

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.


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?


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.


----------



## fonz (Oct 20, 2014)

kpa said:


> You are not supposed to know what the internal implementation of the PKG database is.


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.


----------



## fonz (Oct 20, 2014)

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.


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@ (Oct 20, 2014)

Tinderbox has been at least partially supplanted by ports-mgmt/poudriere.


----------



## fonz (Oct 20, 2014)

wblock@ said:


> Tinderbox has been at least partially supplanted by ports-mgmt/poudriere.


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.


----------



## ShelLuser (Oct 20, 2014)

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.


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.


----------



## fonz (Oct 20, 2014)

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.


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 (Oct 21, 2014)

wblock@ said:


> No, it did depend on that.  For example, `make deinstall` just used `pkg_delete`.



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.


----------



## kpa (Oct 21, 2014)

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.



From the SVN commit log of /usr/ports/Mk/bsd.port.mk

```
------------------------------------------------------------------------
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


----------



## Chris_H (Oct 27, 2014)

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.


Yes. It was this thread -- about third reply, as I recall. Good analogy, BTW. 

--Chris


----------



## jb_fvwm2 (Oct 27, 2014)

"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.


----------



## wblock@ (Oct 27, 2014)

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,



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).



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@? .



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.



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.


----------



## rmoe (Oct 28, 2014)

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.


----------



## jb_fvwm2 (Oct 28, 2014)

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.


----------



## Chris_H (Oct 31, 2014)

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.





			
				chris_h said:
			
		

> I digress...



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.



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 (Oct 31, 2014)

> ... DEFAULT_VERSIONS ...



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.


----------



## wblock@ (Oct 31, 2014)

The Poudriere section: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-poudriere.html

Incidentally, if anyone wants to collaborate on documentation, please contact me.


----------



## Chris_H (Oct 31, 2014)

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...


You can grep(1) for it in the ports/Mk/ files. Sorry. I can't remember which one, off the top of my head. 

--Chris

EDIT: DEFAULT_VERSIONS, that is.


----------

