Re: CVS commit: pkgsrc/sysutils

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%mnx.io@localhost> writes:

> * On 2023-08-23 at 13:53 BST, Greg Troxel wrote:
>
>>Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:
>>
>>> It may be new behavior; in the past I did run into an installed package
>>> that was not in the new repository (e.g. because it didn't build and
>>> I didn't notice). In this case, pkgin would just ignore it and I ended
>>> up with a non-working binarie (because shared libs of dependancies got bumped).
>>
>>jperkin has been working away making pkgin better.  Bug reports help, so
>>it would be good to try this out.
>
> FWIW this is still the current behaviour.  The thing to consider here
> is that the pkgdb does not record where a package was installed from,
> and so there's currently no way to distinguish between a package
> installed from a remote repository (where you would want to be
> notified that an
> update is missing), and one that was e.g. built locally and installed
> manually using pkg_add (where you would not).

To me the real point is

  If you pkgin ug to a new repo, and there is an installed package not
  in the repo, then all dependencies of that installed package should be
  protected from upgrades without a warning/confirmation.

I say 'protected from upgrades', because we have no way to now that if
foo which is not present depends on A, then if we get A', will foo be ok
with that.

I would rather view "packages installed not from the repo" as
second-class/irregular than have trouble in the main path of "all
packages are from the repo".

If that means people who have packages from other sources get extra
warnings, I think that's fine.

> There are some options to enhance the pkgdb in this regard, e.g. a new
> +INSTALLED_INFO variable that records the repository, but that throws
> up further questions like how do you accurately track that a
> repository URL switch from e.g. 2023Q2 to 2023Q3 should be considered
> as the same source repository?

I don't think that really fixes the issue at hand.

> An incomplete alternative approach, assuming they are recorded
> correctly (which may not be the case for any self-built packages), is
> to check all of the REQUIRES for installed packages and their proposed
> updates against the incoming PROVIDES to look for any missing
> dependencies.  Of course this only takes into account shared library
> dependencies, and wouldn't help in the case where there is a
> dependency on a particular binary which is either removed or renamed.

In general, I do not think that one can ever decide that an upgraded
dependency for an installed package not in the repo is safe.


(moved to tech-pkg)