pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Why are depends rebuilt on "bmake update" ?

On Thu, Oct 25, 2012 at 10:04 AM, Alan Barrett <> 
> Yes, that can easily happen.  I have most often seen it when a package
> is split.  For example:
>    T1:  You install usefulpkg-1.0, which depends on sometool-1.0
>    T2:  sometool version 2 is released, and pkgsrc decides to
>         split it into sometool-base-2.0 and sometool-2.0,
>         with sometool-2.0 depending on sometool-base-2.0.
>         sometool-base-2.0 is marked as conflicting with sometool-1.0.
>         pkgsrc changes usefulpkg-1.0nb1 to depend on sometool-base-2.0,
>         where usefulpkg-1.0 used to depend on sometool-1.0.
>    T3:  You update your pkgsrc tree, and run pkg_rr.
>         pkg_rr wants to upgrade usefulpkg from version 1.0 to 1.0nb1.
>         pkg_rr needs to build sometool-base-2.0 as a dependency for
>         usefulpkg-1.0nb1
>         sometool-base-2.0 can't be installed, because it conflicts with
>         sometool-1.0.
>    T4:  You figure out what's wrong, manually delete sometool-1.0,
>         run pkg_rr again, and now it works.

Absolutely the same things happen not only with pkg_rr but also
with binary package managers. In pkgtools/nih for resolving
this kind of issues I remove sometool-1.0 with a help of "pkg_delete -f".
This solves the problem but I'm not satisfied with this approach
because if something bad happens in the middle of update
I'll have broken pkgdb.
Also, I'd prefer not to run "pkg_admin rebuild" for restoring +REQUIRED_BY
in the end.
Another problem is that after "pkg_delete -f", flag "automatic" (pkg_add -A)
is lost as well as other custom flags (in nih I also use "keep" and "try_out"),
so I have to make some thing to restore them.

I think the real problem is in pkg_install. I'd prefer the
functionality in pkg_delete or pkg_admin like the following:

"Run uninstall script, remove all files that belong to the specified package,
remove files from pkgdb listed in +CONTENTS, and then remove all
CONFLICTS entries from pkgdb, but keep everything else".

This is not a final solution. This is the first thing that came to my mind.
Neither "pkg_admin delete" nor "pkg_admin unset" work as needed.

Home | Main Index | Thread Index | Old Index