# pkg doesn't respect DEFAULT_VERSIONS



## YuryG (Dec 25, 2017)

I have `DEFAULT_VERSIONS+= ruby=2.3` in make.conf
but since last upgrade (a couple of days ago) `pkg version -v` says I should upgrade to 2.4 version also making some dependant ports look "orphaned" (ruby23-bdb-0.6.6_5, ruby23-gems-2.6.14, ruby23-gems-2.6.14) in that output.
Also, there's no mentioning of bumping default version of ruby to 2.4 in UPDATING.
Or I'm wrong?


----------



## ShelLuser (Dec 25, 2017)

I can't reproduce any issues with this. Just curious: do you happen to have VERSION_SOURCE set in pkg.conf and if so: what is it set to?


----------



## YuryG (Dec 25, 2017)

ShelLuser said:


> VERSION_SOURCE set in pkg.conf


No.
I use `portupgrade` to install and upgrade ports. `pkg`, as I can see it, is a system of managing dependencies (among of other things it can do). So, after `portsnap fetch update` I check /usr/ports/UPDATING if anything to take in account manually and do `pkg version -v` to check what specifically should be upgraded. Usually, `pkg` respects `DEFAULT_VERSIONS` that are set in make.conf. But not in this case.


----------



## marino (Dec 25, 2017)

of course pkg doesn't respect DEFAULT_VERSIONS.  That only applies to building from source.
Whatever the repository that is being fetch has, that's what is "respected".

Expecting pkg to react to the contents of make.conf reflects a fundamental misunderstanding of how binary packages and ports relate to each other.


----------



## ljboiler (Dec 25, 2017)

YuryG said:


> Also, there's no mentioning of bumping default version of ruby to 2.4 in UPDATING.


This definitely should have been done.  Somebody is getting sloppy.


----------



## YuryG (Dec 25, 2017)

marino said:


> of course pkg doesn't respect DEFAULT_VERSIONS.  That only applies to building from source.
> Whatever the repository that is being fetch has, that's what is "respected".
> 
> Expecting pkg to react to the contents of make.conf reflects a fundamental misunderstanding of how binary packages and ports relate to each other.


O.K. And what `pkg info -r` or `pkg version` concerning built from source ports? And should somehow it show me "needs upgrade" (or "orphaned") with other ports used in different versions than current in binary repo?


----------



## marino (Dec 25, 2017)

I don't understand your question.
Let me answer like this:
*IF* you want defaults to be set differently than what the official FreeBSD packages have, then you *must* build at least some packages yourself.  Ideally you build all your packages locally and point your pkg(8) program to the local repository.  Then pkg(8) will show correctly what is available to upgrade (assuming you already built the new packages locally).

synth will allow mixing of official freebsd packages and adding them to a local repository.  Some people like this feature although I would still recommend building everything yourself if you have the server power to do so.


----------



## YuryG (Dec 25, 2017)

Well. I use ports for everything. (So, I do NOT use `pkg install`) When upgrading ports' tree with `portsnap fetch update` how should I know what to upgrade next? I used to use `pkg version`, also I had no troubles with `pkg info` to know dependencies etc. when using ports (and respecting OPTIONS for each port, yes?).
Also, as I can see, my behaviour complies with Handbook 4.5.3.
Not sure I am understanding your idea.


----------



## marino (Dec 25, 2017)

well, make sure your `pkg version` uses the ports tree index for comparison and not the official remote repository.  The ports and packages are almost never in sync on FreeBSD.

You say you don't understand my idea.
Well, I don't understand what you're not understanding.


----------



## talsamon (Dec 25, 2017)

Set in the `DEFAULT_VERSIONS`related ports Makefile  (like lang/php, lang/ruby , databases/bdb, etc)  something like an update flag or a function in the related bsd.XXX.mk. (or in bsd.default-versions).
Something like (pseudo-code):

```
.if (${NEW_VERSION} != ${VERSION_WHICH_IS_SET_NOW})
${ECHO} "your version is set to ${VERSION_WHICH_IS_SET_NOW} (or not set)"
${ECHO} "warn DEFAULT_VERSION has bumped to ${NEW_VERSION}"

#maybe, here a description what to do
.endif
```
(maybe an DEFAULT_VERSION_CHANGE flag yes/no -- only in use if no DEFAULT_VERSION is set - which can be enabled/disabled in make.conf and exits the update  if it is changed).

It is an ugly warning but no maintainer could  forget to make an entry in /usr/ports/UPDATING.


----------



## YuryG (Dec 26, 2017)

My question is: *why* `pkg version -v` says me that my ruby “needs updating” if it proposes me the other major version (2.3 and 2.4)? Also, I suppose that `pkg`'s “orphaned” messages are related to that my installed ports — ruby23-bdb-0.6.6_5, ruby23-gems-2.6.14, ruby23-gems-2.6.14 — “belong” only to 2.3 ruby, not 2.4 (and there are corresponding directories in /usr/ports despite the messages). So, how to *correctly* know what really need updating in my case?

How should I be sure that “`pkg version` uses the ports tree index for comparison and not the official remote repository” if I am following all the recommendations in Handbook 4.5? So, I do not understand why do you suggest me to use `synth` “to build packages locally” if I use ports and `portupgrade` and no packages?


----------



## tankist02 (Dec 26, 2017)

YuryG By default pkg operates with the official remote FreeBSD repository. You say you build all your packages locally using the ports tree. So when you use pkg version you are comparing different things. Personally I use this command if I need to check the ports vs my installed packages:


```
# portmaster -L | grep -B 1 "New version"
===>>> faad2-2.8.6,1
   ===>>> New version available: faad2-2.8.8,1
--
===>>> jpeg-turbo-1.5.2
   ===>>> New version available: jpeg-turbo-1.5.3
--
===>>> libdrm-2.4.88,1
   ===>>> New version available: libdrm-2.4.89,1
--
===>>> mesa-dri-17.3.0
   ===>>> New version available: mesa-dri-17.3.1
===>>> mesa-libs-17.3.0
   ===>>> New version available: mesa-libs-17.3.1
--
===>>> openjdk8-8.152.16_1
   ===>>> New version available: openjdk8-8.152.16_2
--
===>>> samba46-4.6.11
   ===>>> New version available: samba46-4.6.12
--
===>>> firefox-57.0.2,1
   ===>>> New version available: firefox-57.0.2_1,1
--
===>>> vim-8.0.1397
   ===>>> New version available: vim-8.0.1424
```


----------



## ShelLuser (Dec 26, 2017)

YuryG said:


> My question is: *why* `pkg version -v` says me that my ruby “needs updating” if it proposes me the other major version (2.3 and 2.4)?


Because some local settings no doubt. This is what I meant when I mentioned that I can't reproduce any issues.

Example: Apache's default version is 2.4 according to /usr/ports/Mk/bsd.default-versions.mk. My installed version however is 2.2 and I've set DEFAULT_VERSIONS accordingly.


```
$ pkg version -vx apache
apache22-2.2.34_1                  =   up-to-date with index
```
And this also applies to other software as well.



YuryG said:


> How should I be sure that “`pkg version` uses the ports tree index for comparison and not the official remote repository” if I am following all the recommendations in Handbook 4.5?


Check pkg-version(8). It does so by default unless you specify another command line parameter or have overridden this setting in pkg.conf.

(edit): There's a bit more to this, but the manpage will explain. When the INDEX doesn't exist it'll fall back to the ports collection and when that doesn't exist it'll fall back to an online repository.

So if you wish to enforce this then you could use `pkg version -Ix ruby` optionally followed by an index file. To be sure that you're using the correct index file check /etc/portsnap.conf to see which index file(s) are build and/or maintained. Optionally you could specify one of those.

In my environment it lists INDEX-9 and INDEX-10 so to enforce a proper lookup I'd use:


```
$ pkg version -Ivx apache /usr/ports/INDEX-10
apache22-2.2.34_1                  =   up-to-date with index
```

Hope this can help.


----------



## YuryG (Dec 26, 2017)

O.K. I haven't modified pkg.conf nor portsnap.conf. So, it uses /usr/ports/INDEX-10.
Also, I have `DEFAULT_VERSIONS+= ruby=2.3` in make.conf. But

```
$ pkg version -Iv /usr/ports/INDEX-10 | grep "<"
faad2-2.8.6,1                      <   needs updating (index has 2.8.8,1)
ruby-2.3.6,1                       <   needs updating (index has 2.4.3,1)
$
$ pkg version -Ix ruby /usr/ports/INDEX-10
ruby-2.3.6,1                       <
ruby23-bdb-0.6.6_5                 ?
ruby23-gdbm-2.3.6_3,1              ?
ruby23-gems-2.6.14                 ?
rubygem-hpricot-0.8.6              =
rubygem-mustache-1.0.5             =
rubygem-rake-12.3.0                =
rubygem-rdiscount-2.2.0.1          =
rubygem-ronn-0.7.3                 =
```
I have other non-standard versions set in make.conf and have no trouble with them. Say, I have `python3=3.5` and default now is 3.6, but I do not see any `<` signs in `pkg version -Ix python` output.
Only with ruby I have the problem. So, my topic exists. Where to check more?


----------



## talsamon (Dec 27, 2017)

Yes, there is something wrong. I had the same problem before I upgraded to lang/ruby24 (but I guessed the cause wrong). I had the same output(Thread 63848).


----------



## PacketMan (Dec 27, 2017)

I never used ports-mgmt/portupgrade but did use ports-mgmt/portmaster in the past.  With portmaster you can issue the command `portmaster -L` and it will tell you if port upgrades are available.

In portupgrade(1) I see these notes:
     +o    To check for available   upgrades, give portversion(1) a   try instead of
    pkg_version(1).  It has comparable usage with pkg_version(1) but runs
    much faster.  Also the   output script of ``portversion -c'' utilizes
    portupgrade(1)   for upgrading.


----------



## ljboiler (Dec 27, 2017)

If your INDEX-10 already believes that the "default" version of ruby has been bumped to 2.4 then wouldn't what you seen happening be expected?

Try this:
	
	



```
grep '^ruby\-' /usr/ports/INDEX-10 | cut -d '|' -f1
```


----------



## YuryG (Dec 27, 2017)

PacketMan said:


> …To check for available   upgrades, give portversion(1) a   try instead of pkg_version(1).


Thanks!

```
$ portversion -v | grep ruby
ruby-2.3.6,1                =  up-to-date with port
...
```
P.S.
But!

```
py27-gdbm-2.7.14_4          <  needs updating (port has 3.6.4_4)
py27-sqlite3-2.7.14_7       <  needs updating (port has 3.6.4_7)
py27-tkinter-2.7.14_6       <  needs updating (port has 3.6.4_6)
ruby23-gdbm-2.3.6_3,1       <  needs updating (port has 2.4.3_3,1)
```


----------



## YuryG (Dec 27, 2017)

ljboiler said:


> If your INDEX-10 already believes that the "default" version of ruby has been bumped to 2.4 then wouldn't what you seen happening be expected?
> 
> Try this:
> 
> ...


Indeed. This command gives:

```
ruby-build-20171215
ruby-subversion-1.9.7
ruby-2.4.3,1
ruby-rd-mode.el-0.6.38
```
I feel confused. How's that?


----------



## tobik@ (Dec 27, 2017)

If you want the INDEX to accurately reflect your own customized /etc/make.conf you'll have to generate it yourself (i.e. `make -C /usr/ports index`) and not just fetch it from the FreeBSD cluster (which uses ports tree defaults to generate it and the package names and versions in it reflect this).


----------



## YuryG (Dec 27, 2017)

tobik@ said:


> If you want the INDEX to accurately reflect your own customized /etc/make.conf you'll have to generate it yourself (i.e. `make -C /usr/ports index`)…


After each `portsnap fetch update`?


----------



## ljboiler (Dec 27, 2017)

It appears that the INDEX file is part of the ports snapshot, so the answer would be yes.


----------



## marino (Dec 27, 2017)

you can also switch pkg version to use ports directly instead of the index.


----------



## SirDice (Dec 28, 2017)

If you use portsnap(8) there's no need to generate an INDEX file. You would only need to do this if you update your ports tree with SVN or Git. 

Also note that you don't need to add the INDEX file to the pkg-version(8) command. The -I option already takes care of this. 

`pkg version -vI` # Gets the versions and compares them against the local INDEX.
`pkg version -vR` # Gets the versions and compares them against the remote repository


----------



## marino (Dec 28, 2017)

SirDice@, I don't think you are following the topic correctly.
He *does* need to generate an INDEX file if he's using pkg(8) to scan the index file to determine if the install packages are out of date.  That's the point of the topic.  If he changes pkg(8) to scan the ports directly, then he wouldn't need it.
Neither of your suggested commands work.  The first is what's he's already doing and the second doesn't work because he's changed the defaults from the official FreeBSD settings.


----------



## SirDice (Dec 28, 2017)

marino said:


> He *does* need to generate an INDEX file if he's using pkg(8) to scan the index file to determine if the install packages are out of date.


pkg(8) doesn't use INDEX, pkg-version(8) uses the INDEX. But besides that, if you update the ports tree with portsnap(8) the INDEX is already updated before the diffs are made. So with portsnap(8) the INDEX would be correct. Thus no need to run `make -C /usr/ports index`. However, if you update the ports tree with SVN or Git the INDEX may not be updated and in that case you would need to generate an updated one with `make index`. 



marino said:


> The first is what's he's already doing and the second doesn't work because he's changed the defaults from the official FreeBSD settings.


Changing any of the DEFAULT_VERSIONS doesn't change anything in the INDEX. The INDEX is generated based on the contents of the Makefile of the ports.


----------



## marino (Dec 28, 2017)

You're still not getting it.
1) pkg-version is just `pkg version`.  I'm not sure why you are making the distinction.  it's still pkg(8)
2) The point is in yuri's case, the provided INDEX is WRONG.  thus he needs to generate it so it's RIGHT for HIM



> Changing any of the DEFAULT_VERSIONS doesn't change anything in the INDEX. The INDEX is generated based on the contents of the Makefile of the ports.


That's the ENTIRE point.  Because he changed the DEFAULT_VERSIONS, the index is wrong for him.  If he generates it himself, that new index does account for make.conf changes.  That's the entire conversation of this thread.


P.S.  And his new INDEX is only needed if he tells `pkg version` to check versions via index.  If he tells it to check versions by using make against the ports tree, he doesn't need a regenerated index.


----------



## SirDice (Dec 28, 2017)

marino said:


> The point is in yuri's case, the provided INDEX is WRONG. thus he needs to generate it so it's RIGHT for HIM


Then just nuke /usr/ports and do a full `portsnap fetch extract` and be done with it. 



marino said:


> Because he changed the DEFAULT_VERSIONS, the index is wrong for him.


As far as I know the _content_ of the INDEX file doesn't change if you change any of the DEFAULT_VERSIONS. So I don't see why it would need to be recreated/generated if DEFAULT_VERSIONS is changed.


----------



## marino (Dec 28, 2017)

SirDice said:


> Then just nuke /usr/ports and do a full `portsnap fetch extract` and be done with it.



Which leaves him with a fresh, incorrect copy.
The portsnap INDEX is only accurate for users that not configured the options of a single port or changed the defaults. 



> As far as I know the _content_ of the INDEX file doesn't change if you change any of the DEFAULT_VERSIONS. So I don't see why it would need to be recreated/generated if DEFAULT_VERSIONS is changed.



well, you know incorrectly.  a regenerated index reflects the set options and defaults of the system generating it.
Try it.  Change a port option or default that affects dependencies, then generate the index yourself and compare to the provided INDEX.  Then try again with a ports tree with no customization.  The INDEX on the latter tree should match what portsnap provides assuming you're on the same SVN revision.  THe former will not.

P.S. or just generate the index, save it, change an option or default, and generate again, then note the newest index does not match the saved one (thus clearly options/defaults affects the contents of the index)


----------



## SirDice (Dec 28, 2017)

marino said:


> P.S. or just generate the index, save it, change an option or default, and generate again, then note the newest index does not match the saved one (thus clearly options/defaults affects the contents of the index)


Actually, I did just that. There were zero changes regardless of what I changed in DEFAULT_VERSIONS.

Edit: I stand corrected. It appears I was working with an older ports tree. It does indeed appear to change. Nice, learned something new today


----------

