Re: Following current - pkg_add update forward depedencies don't match question
I also found twice that removed (from ports permanently) packages I had installed would throw things into a loop that once caused me to run out of memory or things just kept looping. ^C followed by pkg_delete -i "the offending package" then resuming pkg_add -u made things much easier. Overall the pkg_ tools have been great and always improving. Thank you for the hard work! Overall, following -current locally and remotely has become so incredibly easy now that I am running -current everywhere and really happy! (and resuming work on porting because of it) Thanks again! Chris Bennett
Re: Following current - pkg_add update forward depedencies don't match question
> -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Stuart Henderson > Sent: Sunday, November 03, 2019 7:59 AM > To: misc@openbsd.org > Subject: Re: Following current - pkg_add update forward depedencies > don't match question > > On 2019-11-02, Theodore Wynnychenko wrote: > > I decided to just try updating gettext, so (this is the full output > on that > > system): > > Well, that's the problem. Partial updates work sometimes but they can't > be relied upon, in particular won't work around some types of > restructuring > changes as happened to the gettext port. > I tried running 'pkg_add -u' (not as a partial update) probably 5-10 times, always getting the same 'forward dependencies don't match' notice, and pkg_add ending with the notices: Couldn't find updates for ... gettext-0.19.8.1p3 ... (and all the other 'don't match' packages) Couldn't install gettext-runtime-0.20.1p0 ... (and all the other 'don't match' packages) > Flavours are after the version number (mutt-1.12.2v3-gpgme: this is the > "gpgme" flavour of mutt). > > gettext was split into multiple parts (runtime, tools, and > libtextstyle) > in separate packages and there is no more package just named "gettext". > Say you have A+B installed and want to update them, both use gettext. > A(old)+B(old) depend on gettext; A(new)+B(new) depend on gettext- > runtime. > gettext and gettext-runtime contain same files so can't be installed > together. Therefore you can't update A(old) to A(new) without also > updating B(old) to B(new). > In my case, pkg_add -u did not succeed regardless of whether or not it was a complete update. > > Now, I really have little idea of what this means, or what I am > doing, but I > > decided I would just manually "fix" the @depend line in my local > > "/var/db/pkg/[package]/+CONTENTS" to the "new" line (with > > "gettext-runtime-0.20.1p0" in it). > > That probably didn't cause any big problems in this case, but I just > want > to make sure that it's showing in the thread for the list archives: > don't > do that :-) > I agree that it did not seem like the best idea (a little knowledge is a dangerous thing). When I was thinking about it, I thought of deleting gettext (so that I could install gettext-runtime), but that seemed to lead to a lot of other required package deletions, and I was worried that something would break. I could not figure out how to get one package (in this case, getext) to be deleted, for just a few minutes, so that I could install gettext-runtime without being forced to accept the deletion of a bunch of other packages. Is there a way to do something like that? I could not find one. > I would suggest running pkg_check now for a sanity check of the package > database. > Did that immediately after the update - I guess I got something right :-) Thanks again Ted
Re: Following current - pkg_add update forward depedencies don't match question
On 2019-11-02, Theodore Wynnychenko wrote: > I decided to just try updating gettext, so (this is the full output on that > system): Well, that's the problem. Partial updates work sometimes but they can't be relied upon, in particular won't work around some types of restructuring changes as happened to the gettext port. > After staring at this for a while, I started to wonder (because it had been > a while since I last updated...) if the fact that "gettext" is now listed as > "getttext-runtime" (I guess this is just a "flavor," right?, but the change > was something I noticed) could be an issue. Flavours are after the version number (mutt-1.12.2v3-gpgme: this is the "gpgme" flavour of mutt). gettext was split into multiple parts (runtime, tools, and libtextstyle) in separate packages and there is no more package just named "gettext". Say you have A+B installed and want to update them, both use gettext. A(old)+B(old) depend on gettext; A(new)+B(new) depend on gettext-runtime. gettext and gettext-runtime contain same files so can't be installed together. Therefore you can't update A(old) to A(new) without also updating B(old) to B(new). Not that this is necessary to know in this case - just remember that after updating base, you need to run pkg_add -u to update all packages. Maybe add -Dsnap if the conditions require it, and flags like -V/-i are ok, but the other pkg_add -D flags are for special cases only, usually just for ports developers. > I then looked at the pkg_info for one of the "don't match" packages on my > system, and compared them to the new/current packages. > > So, for a local problem package I saw (in the depend list): > @depend devel/gettext:gettext-*:gettext-0.19.8.1p3 > > When I looked at the -current package I saw: > @depend devel/gettext,-runtime:gettext-runtime-*:gettext-runtime-0.20.1p0 > > Now, I really have little idea of what this means, or what I am doing, but I > decided I would just manually "fix" the @depend line in my local > "/var/db/pkg/[package]/+CONTENTS" to the "new" line (with > "gettext-runtime-0.20.1p0" in it). That probably didn't cause any big problems in this case, but I just want to make sure that it's showing in the thread for the list archives: don't do that :-) > I did that for all the "don't match" conflict packages, then re-ran "pkg_add > -vui -Dsnap" (although, I now understand the need or lack thereof for > "-Dsnap" better - thanks) and the package update completed without any real > issues. Specifically, gettext and all the "don't match" packages were > updated to the -current packages available yesterday. > > As I said, I have little idea of what I am doing, but this (at least for the > last 30 hours) seems to have worked and the system appears to be "stable" > (and, once again, -current). I would suggest running pkg_check now for a sanity check of the package database.
Re: Following current - pkg_add update forward depedencies don't match question
> -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Stuart Henderson > Sent: Saturday, November 02, 2019 4:12 AM > To: misc@openbsd.org > Subject: Re: Following current - pkg_add update forward depedencies > don't match question > > On 2019-11-01, Theodore Wynnychenko wrote: > > Hello > > > > I just updated a system to current the other day. > > > > OpenBSD 6.6 GENERIC.MP#411 amd64 > > > > The last time I updated was probably 2-3 months ago. > > > > Anyway, when I went to updated packages (also following > current/snapshots), > > I got a number of "forward dependencies - don't match" notices and > the > > packages don't update. > > What command are you running to update? > > The "don't match" are expected but (at least with "pkg_add -u" without > restricting to a subset of packages) it shouldn't stop packages from > updating anyway. > > Can you show the pkg_add command line you're using and complete output? > i.e. run it under script(1) and send the typescript. > > This doesn't match "probably 2-3 months ago", php 5.6 and the > associated > pecl packages were removed before 6.5, and php-7.1.27 was from > somewhere > between 6.4 and 6.5. Not that this matters in itself, an update over > that time period would still be expected to work, but if you're > going to be updating infrequently you should definitely stick to > releases+syspatch rather than -current. > Sorry, it was probably longer than "2-3 months." Life got in the way. I should do better going forward, and I understand that going "back" to release from current can be problematic. In any case, I wanted to describe my "experience" with this issue. I will try to be brief. Yesterday afternoon, I noticed that the timestamps for packages had updated. So, I tried again (on another system where "breaking" is less consequential). I decided to just try updating gettext, so (this is the full output on that system): # PKG_PATH=https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ pkg_add -u -Dsnap gettext quirks-3.184 signed on 2019-11-01T17:28:51Z .libs1-gettext-0.19.4p0+gettext-0.19.8.1p3->gettext-runtime-0.20.1p0 forward dependencies: | Dependencies of python-2.7.16 on gettext-* don't match | Dependencies of python-3.6.8p0 on gettext-* don't match | Dependencies of libidn-1.35 on gettext-* don't match | Dependencies of glib2-2.58.3p8 on gettext-* don't match | Dependencies of wget-1.20.2 on gettext-* don't match | Dependencies of libpsl-0.20.2 on gettext-* don't match | Dependencies of libgpg-error-1.36 on gettext-* don't match | Dependencies of monitoring-plugins-2.2p7 on gettext-* don't match Merging python-2.7.16->2.7.16p1 (ok) NOT MERGING: can't find update for [python-3.6.8p0] (ok) Merging libidn-1.35->1.35p0 (ok) Merging glib2-2.58.3p8->2.60.7 (ok) Merging wget-1.20.2->1.20.3p1 (ok) Merging libpsl-0.20.2->0.20.2p0 (ok) Merging libgpg-error-1.36->1.36p0 (ok) Merging monitoring-plugins-2.2p7->2.2p8 (ok) Proceed with update anyway ? [y/N/a] y Detected loop, merging sets ok | python-3.7.5 | .libs1-gettext-0.19.4p0+gettext-0.19.8.1p3+glib2-2.58.3p8+libgpg-error-1.36+ libidn-1.35+libpsl-0.20.2+monitoring-plugins-2.2p7+python-2.7.16+wget-1.20.2 ->gettext-runtime-0.20.1p0+glib2-2.60.7+libgpg-error-1.36p0+libidn-1.35p0+li bpsl-0.20.2p0+monitoring-plugins-2.2p8+python-2.7.16p1+wget-1.20.3p1 [python-3.6.8p0].libs-glib2-2.56.1+.libs-libidn-1.34+.libs-libpsl-0.7.1p1+.l ibs1-gettext-0.19.4p0+gettext-0.19.8.1p3+glib2-2.58.3p8+libgpg-error-1.36+li bidn-1.35+libpsl-0.20.2+monitoring-plugins-2.2p7+python-2.7.16+wget-1.20.2-> gettext-runtime-0.20.1p0+glib2-2.60.7+libgpg-error-1.36p0+libidn-1.35p0+libp sl-0.20.2p0+monitoring-plugins-2.2p8+python-2.7.16p1+python-3.7.5+wget-1.20. 3p1 forward dependencies: | Dependencies of python-3.6.8p0 on gettext-* don't match Proceed with update anyway ? [y/N/a] y Can't install [python-3.6.8p0].libs-glib2-2.56.1+.libs-libidn-1.34+.libs-libpsl-0.7.1p1+.l ibs1-gettext-0.19.4p0+gettext-0.19.8.1p3+glib2-2.58.3p8+libgpg-error-1.36+li bidn-1.35+libpsl-0.20.2+monitoring-plugins-2.2p7+python-2.7.16+wget-1.20.2-> gettext-runtime-0.20.1p0+glib2-2.60.7+libgpg-error-1.36p0+libidn-1.35p0+libp sl-0.20.2p0+monitoring-plugins-2.2p8+python-2.7.16p1+python-3.7.5+wget-1.20. 3p1: can't resolve gettext-* Couldn't find updates for .libs-glib2-2.56.1 .libs-libidn-1.34 .libs-libpsl-0.7.1p1 .libs1-gettext-0.19.4p0 gettext-0.19.8.1p3 glib2-2.58.3p8 libgpg-error-1.36 libidn-1.35 libpsl-0.20.2 monitoring-plugins-2.2p7 python-2.7.16 wget-1.20.2 Couldn't install gettext-runtime-0.20.1p0 glib2-2.60.7 libgpg-error-1.36p0 libidn-1.35p0
Re: Following current - pkg_add update forward depedencies don't match question
On 2019/11/02 05:04, Chris Bennett wrote: > On Sat, Nov 02, 2019 at 09:24:05AM -, Stuart Henderson wrote: > > On 2019-11-01, Chris Bennett wrote: > > > NO. You need to use pkg_add -u -Dsnap. > > > > Normally when pkg_add doesn't have a full path to the package directory > > (e.g. PKG_PATH=http://mirror/pub/OpenBSD/6.6/packages/amd64/) > > it constructs it from a hostname in PKG_PATH or a partial path in > > /etc/installurl. To do that it has to add e.g. 6.6/packages/amd64 > > to the partial path. > > > > It decides whether to use 6.6/ (or other version number) or snapshots/ > > based on whether the current version is a snapshot or not (from the > > "sysctl kern.version" output). > > > > All that -Dsnap does is say "use snapshots/ even if this looks like > > it's a release (no suffix after "6.6"). You only ever need it if you're > > a) running snapshota and b) are in the brief period in the run-up to > > release where the version number has no suffix. > > > > > Occasionally you might need to use sysupgrade -s. That happened to me > > > from one -current to another. > > > > sysupgrade -s is sysupgrade's equivalent to pkg_add -Dsnap. So again you > > would only ever need it directly in the run-up to release. > > > > > > This happened to me with a snapshot from before -release and getting a > snapshot right after -release. Perhaps this should be mentioned in man > sysupgrade(8)? The error message ftp something was not intuitive. > sysupgrade -s is logical and reasonable, but wasn't at all obvious from > the error message. I have had the same error message when a connection > was a problem. > In any case, I was able to fix the problem. > > Thanks, > Chris Bennett > > The error message is better now (post-6.6) though there is still some room for improvement (can't currently move from "6.6-beta" to "6.6" via sysupgrade without hacking the script slightly). Getting the amount of documentation right is a bit of a balancing act, it could be written in more explicit detail, but it makes the doc more complex for something which is only needed over a ~10 day period.
Re: Following current - pkg_add update forward depedencies don't match question
On Sat, Nov 02, 2019 at 09:24:05AM -, Stuart Henderson wrote: > On 2019-11-01, Chris Bennett wrote: > > NO. You need to use pkg_add -u -Dsnap. > > Normally when pkg_add doesn't have a full path to the package directory > (e.g. PKG_PATH=http://mirror/pub/OpenBSD/6.6/packages/amd64/) > it constructs it from a hostname in PKG_PATH or a partial path in > /etc/installurl. To do that it has to add e.g. 6.6/packages/amd64 > to the partial path. > > It decides whether to use 6.6/ (or other version number) or snapshots/ > based on whether the current version is a snapshot or not (from the > "sysctl kern.version" output). > > All that -Dsnap does is say "use snapshots/ even if this looks like > it's a release (no suffix after "6.6"). You only ever need it if you're > a) running snapshota and b) are in the brief period in the run-up to > release where the version number has no suffix. > > > Occasionally you might need to use sysupgrade -s. That happened to me > > from one -current to another. > > sysupgrade -s is sysupgrade's equivalent to pkg_add -Dsnap. So again you > would only ever need it directly in the run-up to release. > > This happened to me with a snapshot from before -release and getting a snapshot right after -release. Perhaps this should be mentioned in man sysupgrade(8)? The error message ftp something was not intuitive. sysupgrade -s is logical and reasonable, but wasn't at all obvious from the error message. I have had the same error message when a connection was a problem. In any case, I was able to fix the problem. Thanks, Chris Bennett
Re: Following current - pkg_add update forward depedencies don't match question
On 2019-11-01, Chris Bennett wrote: > NO. You need to use pkg_add -u -Dsnap. Normally when pkg_add doesn't have a full path to the package directory (e.g. PKG_PATH=http://mirror/pub/OpenBSD/6.6/packages/amd64/) it constructs it from a hostname in PKG_PATH or a partial path in /etc/installurl. To do that it has to add e.g. 6.6/packages/amd64 to the partial path. It decides whether to use 6.6/ (or other version number) or snapshots/ based on whether the current version is a snapshot or not (from the "sysctl kern.version" output). All that -Dsnap does is say "use snapshots/ even if this looks like it's a release (no suffix after "6.6"). You only ever need it if you're a) running snapshota and b) are in the brief period in the run-up to release where the version number has no suffix. > Occasionally you might need to use sysupgrade -s. That happened to me > from one -current to another. sysupgrade -s is sysupgrade's equivalent to pkg_add -Dsnap. So again you would only ever need it directly in the run-up to release.
Re: Following current - pkg_add update forward depedencies don't match question
On 2019-11-01, Theodore Wynnychenko wrote: > Hello > > I just updated a system to current the other day. > > OpenBSD 6.6 GENERIC.MP#411 amd64 > > The last time I updated was probably 2-3 months ago. > > Anyway, when I went to updated packages (also following current/snapshots), > I got a number of "forward dependencies - don't match" notices and the > packages don't update. What command are you running to update? The "don't match" are expected but (at least with "pkg_add -u" without restricting to a subset of packages) it shouldn't stop packages from updating anyway. Can you show the pkg_add command line you're using and complete output? i.e. run it under script(1) and send the typescript. > For example: > > gettext-0.19.8.1p3->gettext-runtime-0.20.1p0 forward dependencies: >| Dependencies of php-apache-7.1.27p0 on gettext-* don't match >| Dependencies of gnupg-1.4.23p1 on gettext-* don't match >| Dependencies of glib2-2.58.3p8 on gettext-* don't match >| Dependencies of courier-imap-4.18.2p0 on gettext-* don't match >| Dependencies of e2fsprogs-1.42.12p4 on gettext-* don't match >| Dependencies of libgpg-error-1.36 on gettext-* don't match >| Dependencies of python-3.6.8p0 on gettext-* don't match >| Dependencies of samba-4.8.9 on gettext-* don't match >| Dependencies of gdbm-1.16 on gettext-* don't match >| Dependencies of popt-1.16p1 on gettext-* don't match >| Dependencies of aspell-0.60.6.1p8 on gettext-* don't match >| Dependencies of libpsl-0.20.2 on gettext-* don't match >| Dependencies of wget-1.20.2 on gettext-* don't match >| Dependencies of php-7.1.27 on gettext-* don't match >| Dependencies of libidn-1.35 on gettext-* don't match >| Dependencies of monitoring-plugins-2.2p7 on gettext-* don't match >| Dependencies of python-2.7.16 on gettext-* don't match >| Dependencies of courier-authlib-0.68.0p4 on gettext-* don't match >| Dependencies of fetchmail-6.3.26p2 on gettext-* don't match >| Dependencies of pecl56-pecl_http-2.5.6p3 on gettext-* don't match >| Dependencies of p11-kit-0.23.15p0 on gettext-* don't match This doesn't match "probably 2-3 months ago", php 5.6 and the associated pecl packages were removed before 6.5, and php-7.1.27 was from somewhere between 6.4 and 6.5. Not that this matters in itself, an update over that time period would still be expected to work, but if you're going to be updating infrequently you should definitely stick to releases+syspatch rather than -current. > Or (another example), with similar notices about forward dependencies not > matching: > # pkg_info | grep php-7 > php-7.1.27 server-side HTML-embedded scripting language > > And the mirror shows: > php-7.1.32.tgz > > I see that I can "force" the update with "pkg_add -u -D updatedepends". > > It seems like this should be safe to do, but it's not something I have done > before. > > While my system isn't "production" for a large multi-national, I do use it > as a file server and stuff, and it is working right now, and I don't want to > make it not work. > > So, before I did this, I was wondering if there was anything I should > consider/do to address this issue, other than just "forcing" the update? > > I guess, when at its core, I don't really completely understand what the > notice means, and how and why it happened. It means that you have a group of packages that all depend on a specific version of another package, so all must be updated in a single set rather than individually.
Re: Following current - pkg_add update forward depedencies don't match question
On Thu, Oct 31, 2019 at 07:09:49PM -0500, Theodore Wynnychenko wrote: > Hello > > I just updated a system to current the other day. > > OpenBSD 6.6 GENERIC.MP#411 amd64 > When I check: > # pkg_info | grep gettext > gettext-0.19.8.1p3 GNU gettext runtime libraries and programs > > And the mirror shows: > gettext-runtime-0.20.1p0.tgz > > Or (another example), with similar notices about forward dependencies not > matching: > # pkg_info | grep php-7 > php-7.1.27 server-side HTML-embedded scripting language > > And the mirror shows: > php-7.1.32.tgz > > I see that I can "force" the update with "pkg_add -u -D updatedepends". > NO. You need to use pkg_add -u -Dsnap. Or, the packages really don't match yet. Then wait a little. -Dsnap is a must. Some snapshots are also "defective" as in trying some new stuff that will get changed more later. Upgrade again. Occasionally you might need to use sysupgrade -s. That happened to me from one -current to another. If you genuinely need stability, then run -stable. -current makes changes to the C libraries and headers and then recompiles the packages. The packages are the same but C, etc. has changed. Thus the packages have changed on that level. Thus they keep the same Makefiles, but the resulting package binaries are different. Chris Bennett > It seems like this should be safe to do, but it's not something I have done > before. > > While my system isn't "production" for a large multi-national, I do use it > as a file server and stuff, and it is working right now, and I don't want to > make it not work. > > So, before I did this, I was wondering if there was anything I should > consider/do to address this issue, other than just "forcing" the update? > > I guess, when at its core, I don't really completely understand what the > notice means, and how and why it happened. > > Thanks > Ted > > >
Following current - pkg_add update forward depedencies don't match question
Hello I just updated a system to current the other day. OpenBSD 6.6 GENERIC.MP#411 amd64 The last time I updated was probably 2-3 months ago. Anyway, when I went to updated packages (also following current/snapshots), I got a number of "forward dependencies - don't match" notices and the packages don't update. For example: gettext-0.19.8.1p3->gettext-runtime-0.20.1p0 forward dependencies: | Dependencies of php-apache-7.1.27p0 on gettext-* don't match | Dependencies of gnupg-1.4.23p1 on gettext-* don't match | Dependencies of glib2-2.58.3p8 on gettext-* don't match | Dependencies of courier-imap-4.18.2p0 on gettext-* don't match | Dependencies of e2fsprogs-1.42.12p4 on gettext-* don't match | Dependencies of libgpg-error-1.36 on gettext-* don't match | Dependencies of python-3.6.8p0 on gettext-* don't match | Dependencies of samba-4.8.9 on gettext-* don't match | Dependencies of gdbm-1.16 on gettext-* don't match | Dependencies of popt-1.16p1 on gettext-* don't match | Dependencies of aspell-0.60.6.1p8 on gettext-* don't match | Dependencies of libpsl-0.20.2 on gettext-* don't match | Dependencies of wget-1.20.2 on gettext-* don't match | Dependencies of php-7.1.27 on gettext-* don't match | Dependencies of libidn-1.35 on gettext-* don't match | Dependencies of monitoring-plugins-2.2p7 on gettext-* don't match | Dependencies of python-2.7.16 on gettext-* don't match | Dependencies of courier-authlib-0.68.0p4 on gettext-* don't match | Dependencies of fetchmail-6.3.26p2 on gettext-* don't match | Dependencies of pecl56-pecl_http-2.5.6p3 on gettext-* don't match | Dependencies of p11-kit-0.23.15p0 on gettext-* don't match When I check: # pkg_info | grep gettext gettext-0.19.8.1p3 GNU gettext runtime libraries and programs And the mirror shows: gettext-runtime-0.20.1p0.tgz Or (another example), with similar notices about forward dependencies not matching: # pkg_info | grep php-7 php-7.1.27 server-side HTML-embedded scripting language And the mirror shows: php-7.1.32.tgz I see that I can "force" the update with "pkg_add -u -D updatedepends". It seems like this should be safe to do, but it's not something I have done before. While my system isn't "production" for a large multi-national, I do use it as a file server and stuff, and it is working right now, and I don't want to make it not work. So, before I did this, I was wondering if there was anything I should consider/do to address this issue, other than just "forcing" the update? I guess, when at its core, I don't really completely understand what the notice means, and how and why it happened. Thanks Ted
