pkg icon indicating copy to clipboard operation
pkg copied to clipboard

pkg delete should accept -r

Open davidchisnall opened this issue 4 months ago • 11 comments

Many pkg subcommands accept -r to restrict behaviour to a single repository. This is mostly meaningless for pkg del, but it is useful for pkg del -a to be able to restrict deletion to a single repository.

pkg del -a -r {ports repository} should delete all packages from one repository, but not from the other.

davidchisnall avatar Aug 08 '25 15:08 davidchisnall

If the intention is to delete all non-base packages with a single command, then pkg-delete(8) should also support --repository more than once (for multiple repos).

grahamperrin avatar Aug 12 '25 03:08 grahamperrin

if I translate this would mean delete all the packages installed from a given repository as when getting installed the package register where they have been installed from. What should happen if a repository configuration is disabled? (the package remain flagged as installed from the disabled repository) What should happen if a repository is renamed in configuration? (the package remain flagged as installed from the oldname)

bapt avatar Aug 26 '25 15:08 bapt

What should happen if a package exists in multiple repositories?

agrajag9 avatar Sep 01 '25 19:09 agrajag9

Many pkg subcommands accept -r to restrict behaviour to a single repository. This is mostly meaningless for pkg del, . . .

I disagree about "mostly meaningless". Various personal "why" examples follow, none involving "-a", much less use of force with -a:

I made a typo in a glob for pkg delete -g trying to delete various port-packages --and managed to do in a way that caused the pkg delete to greatly damage the system installation that I'd not intended to change at all. (I stopped the delete but not fast enough to avoid such.) As is my standard procedure for having multiple repositories enabled, I would have provided -r FreeBSD-ports if I'd been allowed to, even though I was typing interactive text to a shell prompt.

I do not like having to consider all installed names from all enabled repositories when figuring out what glob to use --or for validating that I've typed something actually sufficient to do the right thing across all the repositories. It is highly rare that I want to do deletes from more than one repository at once. I do not remember ever wanting to do so.

It is vastly more common that I want to delete various port-packages than I want to delete any part of the system: I've yet to want to delete a base-package, other than when some notes for a (pkgbase based) system update explicitly indicated to do so because of how something has changed.

Again, my concerns here are without "-a" being involved, much less a forced -a being involved.

Side notes:

I'm not directly concerned about if the -r NAME notation is allowed to reference disabled repositories (that still have installed packages) vs. its only being allowed for enabled repositories. I would expect it to be allowed to reference an enabled repository.

But I do expect being able to refer to a potential "oldname" after a repository rename would on rare occasion be appropriate and useful. I'd be happy if disabled repositories (above) also was allowed --making the two cases possibly not all that distinct for pkg's implementation.

markmi avatar Sep 01 '25 20:09 markmi

What should happen if a package exists in multiple repositories?

Part 1 of that? : (1) would the same package name be allowed to be installed a 2nd or later time if from different repositories?

Things probably fork off in different directions, depending on the answer.

Part 2 of that? (just for illustration):

(2. 1no) For (1) being no: probably track dealing with the at-most-1 associated respiratory (if it is referenced by the/a -r when there is such) for the at-most-1 install.

(2. 1yes) For (1) being yes: possibly delete all such when there is no -r, otherwise just the -r match(es)? (More complicated, for sure.)

Note: I'm not trying to indicate some sort of significant preference by writing this note. It is more about some exploring of what the original question might refer to.

markmi avatar Sep 01 '25 22:09 markmi

https://github.com/freebsd/pkg/issues/2494#issuecomment-3243175844

What should happen if a package exists in multiple repositories?

This month – before releng/14.2 reaches end of life – is a suitable time to test drm-61-kmod with releng/14.3.

Installation of drm-kmod without specifying a repository should gain:

  • drm-kmod from the FreeBSD repo
  • drm-61-kmod and other packages from FreeBSD-kmods.

Then, deletion of drm-kmod – without force, with or without specifying its repo:

  • deletes drm-kmod without also deleting drm-61-kmod.

https://www.freshports.org/graphics/drm-kmod/#dependencies

https://www.freshports.org/graphics/nvidia-drm-61-kmod/#dependencies

example
root@zfs:~ # echo $0
/bin/csh
root@zfs:~ # pkg install -Fqy drm-kmod
root@zfs:~ # pkg iinfo drm
libdrm-2.4.123,1
root@zfs:~ # pkg install -qy drm-kmod
=====
Message from drm-61-kmod-6.1.128.1403000_5:

--
The drm-61-kmod port can be enabled for amdgpu (for AMD
GPUs starting with the HD7000 series / Tahiti) or i915kms (for Intel
APUs starting with HD3000 / Sandy Bridge) through kld_list in
/etc/rc.conf. radeonkms for older AMD GPUs can be loaded and there are
some positive reports if EFI boot is NOT enabled.

For amdgpu: kld_list="amdgpu"
For Intel: kld_list="i915kms"
For radeonkms: kld_list="radeonkms"

Please ensure that all users requiring graphics are members of the
"video" group.

Please note that this package was built for FreeBSD 14.3.
If this is not your current running version, please rebuild
it from ports to prevent panics when loading the module.
root@zfs:~ # pkg info drm-kmod | grep repository
repository     : FreeBSD
root@zfs:~ # pkg info drm-61-kmod | grep repository
repository     : FreeBSD-kmods
root@zfs:~ # pkg delete drm-kmod
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
drm-kmod: 20250428

Number of packages to be removed: 1

Proceed with deinstalling packages? [y/N]: y
[1/1] Deinstalling drm-kmod-20250428...
[1/1] Deleting files for drm-kmod-20250428: 100%
root@zfs:~ # 

grahamperrin avatar Sep 01 '25 23:09 grahamperrin

https://github.com/freebsd/pkg/issues/2494#issuecomment-3243233438

… I made a typo in a glob for pkg delete -g trying to delete various port-packages --and managed to do in a way that caused the pkg delete to greatly damage the system installation …

Was the match of some FreeBSD-* (base) packages correct for the typo? (Can you share the command, if it's in your shell's history?)

Or, were the matches entirely non-base packages, with an unexpected effect on base? (If so, OS and repos information may be useful.)

Thanks

grahamperrin avatar Sep 01 '25 23:09 grahamperrin

Was the match of some FreeBSD-* (base) packages correct for the typo? (Can you share the command, if it's in your shell's history?)

The history is long gone.

If I had typed correctly, there would have been no match to any FreeBSD-* packages in FreeBSD-base. But there was matching to such because of my typo.

If I had been able to specify which name-space (repository) I was intending on working in, the system (FreeBSD-base) would have been undisturbed by my making the typo. (I'm not making such a claim for the consequences inside FreeBSD-ports.)

markmi avatar Sep 02 '25 00:09 markmi

https://github.com/freebsd/pkg/issues/2494#issuecomment-3224574659

… What should happen if a repository configuration is disabled? (the package remain flagged as installed from the disabled repository)

An installation of drm-61-kmod from the FreeBSD-kmods repo should remain flagged as installed from FreeBSD-kmods:

  • without an additional annotation to indicate the state, or availability, of any repo.

What should happen if a repository is renamed in configuration? (the package remain flagged as installed from the oldname)

When FreeBSD-kmods becomes FreeBSD-ports-kmods (for example, an upgrade to 15.0):

  • the repository annotation of drm-61-kmod should (probably must) remain unchanged.

grahamperrin avatar Sep 02 '25 00:09 grahamperrin

What should happen if a package exists in multiple repositories? . . .

  • drm-kmod from the FreeBSD repo
  • drm-61-kmod and other packages from FreeBSD-kmods.

As I understand it for the context you are specifying:

) drm-kmod only exists in your FreeBSD repository (your naming)

) drm-61-kmod exists in your FreeBSD and your FreeBSD-kmods repositories (your naming)

So it is only the drm-61-kmod that fits the original question above.

Note that, in your example, the package name drm-61-kmod is, apparently, only installed once, from one repository: FreeBSD-kmods . The one in FreeBSD is effectively ignored (not installed) as your example works. So, at no after-drm-61-kmod-installation stage does the example deal with the same drm-61-kmod name but varying repositories across the pkg command sequence.

markmi avatar Sep 02 '25 02:09 markmi

(your naming)

The names are conventional (not mine) in the releng/14.3 context.


Side note, for readers who are not yet aware of FreeBSD package repository name changes within repo configuration files for 15.0:

  • https://github.com/freebsd/freebsd-src/commit/c83705a5756ef2b01e0e5b1430e8c5548d4cca6e (2025-08-27) on main during 15.0-PRERELEASE without an MFC line
  • more explicitly, the change of names "is not going to be merged to 14.x".

grahamperrin avatar Sep 02 '25 06:09 grahamperrin