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" <> writes:

>> I have
>>   DEPENDS_TARGET=         bin-install clean
>> and removing things and rerunning mostly works,
> I'm a little leary of bin-install -- and I'm OK with rebuilding things
> extra times....

Sure, your call.  For me it made me more willing to type "pkgin ar"
frequently.  Right now py27-scons and py39-scons conflict because they
both install "scons", and there isn't USE_TOOLS+=scons to link
py27-scons into .buildlink/tools/bin/scon, so if you have something that
uses py27-scons you need to keep removing it.  And there are other build
tools.  In theory with revbumps it's ok.  Usually it is, not always.
> In the end I just did this:
> 	# pkg_delete -r python27 python37

That's ok as long as you won't want e.g. py39-paho-mqtt as a
non-automatic package, and it's ok anyway if you make a list which you

> Doing the first three (the p5-* ones) also did not remove their entries
> from the perl-5.xx/+REQUIRED_BY file, though I don't quite understand
> why not.

Are you sure, or could it be that there were two entries, and 1 got
removed leaving 1?

> There were a huge number of other p5-* packages too that didn't get
> replaced by the version rebuilt by pkg_rolling-replace, but rather the
> updated version was simply added, so I ended up with a large number of
> "duplicate" entries (i.e. two different versions) in the
> perl-5.xx/+REQUIRED_BY file and had to manually remove them.

Or it was messed up before.   I have seen this, and happening on p5-
rings a bell.

It happens from time to time that there are two entries for a package in
+REQUIRED_BY, and once it happens it persists until cleaned up.

I run "pkg_admin rebuild-tree" which scrubs all of these; that's one
step of what "pkg_admin fsck" ought to do.

> For these cases of duplicate +REQUIRED_BY entries I think maybe that
> pkg_rolling-replace re-built the dependency (e.g. gtar-base) before
> rebuilding the package that required it (e.g. gtar), and I think the

pkg_rr basically always does that, or at least that's the design.

> logic to fiddle with the +REQUIRED_BY file in
> pkgsrc/mk/pkgformat/pkg/ is possibly suspect, though I don't
> quite understand it all yet.

It works correctly almost all the time.  I dimly remember that there was
a bug in an odd case and 60% remember that it was fixed.  If you can
find a bug clearly please let me know.

> (though for my systems the setting for automatic=yes is only reliable on
> systems that only have binary installs using pkgin)

I keep it accurate by running 'pkgin sk' and then 'pkgin uk' or 'pkgin
keep', even on systems where I only build from source (plus bin-install
of packages I have built).  make package-install results in automatic
unset, dependency install results in automatic=yes, and make replace
doesn't change automatic.

Part of why I keep automatic correct is that I run 'pkgin export' on all
my systems of a given version/arch (e.g. netbsd-9 amd64) and union them,
and then set difference from the union to the build machine and then I
build those.  That means my own binary package set is usable on all of
the machines.  (The build machine is just for building; it's a 2008
macbookpro, someday to be a xen domU.)

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index