tech-pkg archive

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

Re: I wish I had a make target that...



    Date:        Thu, 12 Jan 2012 12:02:44 -0500
    From:        Greg Troxel <gdt%ir.bbn.com@localhost>
    Message-ID:  <rmiboq8x39n.fsf%fnord.ir.bbn.com@localhost>

  | So before trying all of this, you should have a situation where pkg_chk
  | reports that there are no mismatched packages.

If only that were possible - I've been meaning to ask about this for ages.
pkg_chk uses its own (cut down) Makefile parser to work out what versions
of packages are in pkgsrc (rather than running make to ask for the value,
which is much much much much slower of course) - most of the time it works
fine, but we are getting more and more packages where the Makefile logic
to determine the correct version number is just beyond pkg_chk's ability.

For me, for a long time, there have been 4 (of the packages I build, which has
never been more thyan about 1/2 of what is available), and they were all
small ones, so just rebuilding them, just in case, which is what I have been
doing, was harmless (stuff like xmltoman which builds in < a minute,
and compat14 which is about as fast) - but just recently, a whole set of
ruby packages have grown beyond pkg_chk's abilities, and now there are
(and for now just my NetBSD 5 subset of packages, which is only about 1/5
of the total) has about a dozen or so that are being rebuilt every time,
because pkg_chk thinks they are out of date (solely because it doesn't deduce
the correct version number from the pkgsrc Makefiles).

It would be nice to find a solution to this before the problem grows even
worse - either make pkg_chk faster, or change the rules for pkgsrc Makefile
setting of the pkgname (from which the version is obtained) to be much
simpler than what is allowed now, so that pkg_chk will be able to cope.

kre



Home | Main Index | Thread Index | Old Index