pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [HEADS UP] pkgsrc default database directory changed



On Sun, 13 Dec 2020 at 19:29:44 +0000, Taylor R Campbell wrote:
> Before we distribute more band-aids on this that might require manual
> intervention, maybe we could step back and assess the situation to
> make sure the issues are being comprehensively addressed, and perhaps
> find a way to do it that is safe, idempotent, and requires no manual
> intervention by users?
> 
> We have a lot of different types of users who might be affected by
> this, and I worry that the pkgdb migration had already gotten out of
> hand before we multiplied the cases that are out there with updates to
> base and pullups to -8 and -9:
> 
> - netbsd-{8,9,HEAD} users using base pkg_install exclusively who have
>   updated
>   . base and pkgsrc
>   . base
>   . pkgsrc
>   . neither
> 
> - netbsd-{8,9,HEAD} users using bootstrapped pkg_install exclusively
>   who {have,haven't} updated pkgsrc
> 
> - netbsd-{8,9,HEAD} users using base pkg_install for main packages but
>   bootstrapped pkg_install for /home/user/pkg or /usr/pbulk or
>   similar, who have updated
>   . base and pkgsrc
>   . base
>   . pkgsrc
>   . neither
> 
> All these need to be multiplied by the different versions of the
> manual intervention we've publicly suggested so far.  Did I miss any
> important cases that we're likely to encounter?

Hi Taylor,

Apologies if this has already been mentioned somewhere and I missed it.
I'd add, there's also the question of binary package users vs. those
who build from source (or those who mix both). Binary package users may
encounter particular sources of trouble/confusion that I haven't seen
discussed.

If a user were to upgrade to the most recent stable branches for 8.2 or
9.1, they'll get the new version of the pkg_install tools with the new
expectations, but they'll be installing packages built on 8.0 or 9.0,
which would still work in /var/db/pkg terms. Where this could be extra
trouble is, there are packages that embed the pkgdb location as a hard-
coded path at build time, e.g., pkgtools/pkg_alternatives.

(Credit goes to pin@ for looking into the pkg_alternatives issue. I'd
looked separately at pkgtools/osabi, as binary packages for it end up
with a hard-coded "pkg_admin -K /var/db/pkg..." in its INSTALL script,
however, that example is harmless in practice. Though any appearance
of the "old" path may cause confusion for those who've migrated.)

Regards,

Dave




Home | Main Index | Thread Index | Old Index