pkgsrc-Users archive

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

Re: upgrading/replacing devel/py27-setuptools (and esp other python things)



"Greg A. Woods" <woods%planix.ca@localhost> writes:

> Many hiccups are simple enough to deal with, e.g. long gone packages
> (especially when I don't care to have them any more) (though they're
> terribly annoying to have to deal with given pkg_rolling-replace's
> rather slow pace at figuring out what it wants to do next, and without
> any way to easily report in one group all the things it will run into
> trouble over)

The -k flag more or less works for this.


> However things that effectively get renamed when upgrading are not dealt
> with at all gracefully by pkg_rolling-replace:

There's renamed, and there's pyN->pyM.  pkg_chk doesn't deal well with
the latter and pkg_rr inherits that behavior.


> RR> Selecting py27-setuptools (devel/py-setuptools) as next package to replace
> RR> Checking if py27-setuptools has new depends...
> /usr/bin/awk: unknown option -expat-[0-9]*:../../textproc/py-expat ignored
>
> /usr/bin/awk: unknown option -expat-[0-9]*:../../textproc/py-expat ignored

That I've never seen.

> So, I was wondering what people normally do in cases like this.
>
> I could just blow away all the packages needing this and then start
> fresh with the current PYPKGPREFIX, but again pkg_rolling-replace isn't
> very good at dealing with packages that have to upgrade/replace
> dependencies it hasn't already accounted for.

I have

  DEPENDS_TARGET=         bin-install clean

and removing things and rerunning mostly works, as long as when you
delete a package you mark things that depend on it with "pkg_admin set
rebuild=YES", or unsafe_depends.   Really the pkg tools should set
unsafe_depends on depending packages when pkg_delete -f is used.

Also  with -k, often the top-level package gets replaced which rebuilds
lots of (this week) py39-foo, leaving a bunch of py38-foo or py27-foo
that are no longer needed.

So I frequently do 'pkgin ar' to drop things I don't need, and not trip
over rebuilding them or conflicts with py27-foo and py39-foo.

> Also, what should I expect to have to do when using the new binary
> packages with "pkgin".  I don't expect "pkgin fug" to work very well on
> its own either, though perhaps it will do better than I expect.

It works pretty well.  You may have to pkgin export, remove things, and
then pkgin add what you want.  I generate a summary file.

It helps to keep a clean list of "keep" vs not.  (keep is true if
automatic=yes is not true.)  And it helps to 'pkgin ar'.

I've been building on one machine (that I don't care if it is up any
particular day) and doing pkgin fug on two servers that I do care
about.  It's been really close to totally ok on the servers, and minor
hiccups on the build machine.


If you don't like this, instead generate a needed list and configure a
small bulk build.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index