Riccardo Mottola <riccardo.mott...@libero.it> writes:
> should I unkeep all stuff I don't know, including dependencies?
> sometimes packages are important, but unknown since dependencies.
> Python is an extreme example: I don't want it (except 2.7 core I need
> to build certain things) but it is pulled in as dependency and all its
> modules too.. from various software, where maybe it is not even a core
> thing.
'keep' is about a package being actively desired. "pkgin ar" will
remove packages if a) they are not actively desired and b) they are not
a dependency of some package that is being kept.
So if you don't actually want it, uk it. If it's needed because of
something you do want, it will stay.
I probably should have python311 marked keep on a few systems because I
run scripts outside of pkgsrc, but I have e.g. py311-paho-mqtt marked
keep (because the script uses that) so I don't mark python.
> I installed pkgin, I don't have it since I am using current, there is
> no repository. I understand that for the operation above no repo is
> needed though.
Correct; it doesn't need one. However you can make one by creating a
summary file from the binary packages you have created (since of course
you keep them :)
# regenerate for pkgin
pkgsum () { ls *gz | xargs pkg_info -X | bzip2 > pkg_summary.bz2; }
> # pkgin sk
> processing remote summary
> (https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/10.99.10/All)...
> pkgin: Could not fetch
> https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/10.99.10/All/pkg_summary.gz:
> Not Found
>
> Do you suggest just pointing it to 10.0 repo to silence it? I don't
> want to mix current with binaries.
No, I suggest making a summary file from your own packages and pointing
to that. Either that or ignoring the warning, or configuring no repo at
all and see how that goes.
> I went for another route. I tried pkg_delete. I hope this one keeps
> correctly track of dependencies with versions! It seems to.
>
> pkg_delete py39-tomli-2.0.1nb1
> Package `py39-tomli-2.0.1nb1' is still required by other packages:
> py39-pyproject_hooks-1.0.0nb1
> py39-build-1.2.1
> py39-setuptools_scm-8.0.4
> py39-hatchling-1.22.5
>
> Then I went up and tried to remove these py39 packages.. and up to the
> tree... I was able to remove them all! No non-python package depended
> on them up to python39 removal. I did the same for python 3.10 and 3.8
> stuff, so I end up with py2.7 and py3.11 which is fine!
If you have done uk, and then ar, this probably would have happened.
> I hope I really didn't break anything.
> I wonder if this is automated by your steps above? I thought
> pkg_rolling-replace -uv would take care of it.
No, pkg_rr does not have any code to deal with multi-version.
> yay :) However lintpksgrc is less happy:
>
> Scan Makefiles: 19598 packages
> Version mismatch: 'py-cairo' 1.18.2nb6 vs 1.26.0nb1
> Unknown package: 'py-gobject' version 2.28.7nb5
> Unknown package: 'py-gtk2' version 2.24.0nb48
> Version mismatch: 'py-setuptools' 44.1.1nb1 vs 69.5.1
>
> again here I think the multi-version is what bites me:
>
> # pkg_info | grep setuptools
> py27-setuptools-44.1.1nb1 New Python packaging system (python 2.x version)
> py311-setuptools-69.5.1 New Python packaging system
yes, more hacking is needed to really fix all this.
I am just pointing out that uk/ar hygiene avoids a lot of grief.
