[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg_add and update
> [... some rationale skipped ...]
>> Can 'pkg_add -D' be adapted for ignoring CONFLICTS field just like it
>> does for DEPENDS? Because this relates to not only my pkgnih but also
>> pkg_rr, pkg_chk, pkgin and others I believe it a common interest. As
>> about files causing CONFLICTS, I think pkg_add should work like the
>> following. While installing A-0.2 files common to A-0.2 and B-0.1 (if
>> any) should be assigned to A-0.2. While installing B-0.2 these common
>> files should not be removed from the file system ignoring the fact they
>> were part of B-0.1.
> I think this is just another workaround.
I believe this workaround could be good enough for existing tools.
Two reasons against "powerful pkg_add" are below.
> My preferred solution would be that pkg_add be improved so that it can
> automatically update all or at least a complex subset of all installed
For such tools as pkg_roling-replace that install packages one by one
building them "in place" subset of packages that must be installed
altogether just cannot be available. I'm not big fun of in-place upgrades
but we have no alternatives when using pkgsrc in unprivileged mode with
no root access. Due to this pkg_rolling-replace will have to 'pkg_delete -f'
packages for removing conflicts preventing stop in the middle of upgrade
> handling this case automatically, and not every tool that sits on top
> of it must learn another way to cope with this kind of problem.
In pkgnih user can set "update plan" by specifying the following
1) packages to install/update and mark them as "installed by user",
2) packages to install/update and mark them as autoremovable (automatic=yes),
e.g. "+pkg_chk +pkg_tarup".
3) packages to remove, e.g. "-libmaa".
Take a note that 3) is mandatory. Let's imagine we have autoinstalled
package A-0.1 and B-0.1 installed by user that DEPENDS on A. Package to
install for upgrade is B-0.2 that CONFLICTS with A because it contains
files present in A-0.1, also B-0.2 DEPENDS on new package C
which in turn also CONFLICTS with A. So, neither A can be removed
without removing B-0.1 nor C can be installed without removing A and B.
As a result you'll need pkg_add able to not only install packages but
also to remove them too as well marking them as installed as a
dependency (automatic=yes) on per-package basis. That is, it will
requires big portions of pkg_delete and new notation for specifying
packages. Also -A will become useless.
Finally pkg_add will look like this
pkg_add B +C -A (I use pkgnih's notation here)
In my opinion it is much easier to keep pkg_add/pkg_delete small and
functional and to have small shell script run on top of them for
implementing more complex tasks. I'm going to extract such a shell
script from 'nih' program.
Best regards, Aleksey Cheusov.
Main Index |
Thread Index |