tech-pkg archive

[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
> packages,
I)

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
process.

> 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.
II)

In pkgnih user can set "update plan" by specifying the following
things:

1) packages to install/update and mark them as "installed by user",
e.g. "pkg_rolling-replace".

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.


Home | Main Index | Thread Index | Old Index