pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
pkg/35567: pkgsrc (binary packagre) extra info request
>Number: 35567
>Category: pkg
>Synopsis: pkgsrc (binary packagre) extra info request
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: pkg-manager
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Thu Feb 08 09:45:00 +0000 2007
>Originator: Robert Elz
>Release: NetBSD 3.99.15 (All versions & all versions of pkgsrc)
>Organization:
Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 3.99.15 NetBSD 3.99.15
(GENERIC-1.696-20060125) #8: Wed Jan 25 04:59:39 ICT 2006
kre%jade.coe.psu.ac.th@localhost:/usr/obj/current/kernels/JADE_ASUS i386
Architecture: i386
Machine: i386
>Description:
I have filed this as a pkg category change request
(the ;ackage would be pkgtools/pkg_install I believe)
but it cuold also be a bin category against usr.sbin/pkg_install
I've never been sure which of those is the master, and which
the copy...
I'd very much like to see bnary packages add one extra info
field (variable, whatever you want to call it, or however it
should be implemented) to indicate the source pkgsrc directory
(eg: graphics/png) from which the binary package was constructed.
For most packages this won't add much useful, as the source
directory (the pkgsrc source directory) is trivial to guess,
and the obvious guess is correct 99% of the time.
With a few packages, guessing is just plain annoying, with
others, it is close to impossible (and things get much worse
when a package is removed, and the source directory no longer
exists).
Recording the source directory would make tracking what
happened to a binary package (and just finding the place in which
it can be reconstructed) much easier, at almost no cost.
Even in the case of removed (or moved) packages (in all cases
but repository move, which is thankfully rare) this enables
tracking what happened, as the CVS Attic remains to give a
log of what happened, and why.
>How-To-Repeat:
Just wonder from where a binary package originates, then
see if you can find a way (other than enumerating the names
of every existing package and comparing - using an intelligent
compare, as version numbers can differ, and the py-* and ruby-*
binary package naming makes things interesting)
I have been wanting this for ages - I currently use a (very ugly)
heuristic script to guess for me, but it keeps failing...
Most recently, I found I needed this when lintpkgsrc (-p) told
me that my binary package py24-gtk-0.6.11nb3.tgz was no longer
current. What I typically do in that case, is find the
pkgsrc directory, and rebuild. The rebuild is easy, the "find"
not so easy (even when one knows that pyNN-* packages are found in
py-* pkgsrc directories). I last compiled py24-gtk-0.6.11nb3.tgz
last August. I have no idea from which pkgsrc directory.
x11/py-gtk seems to have been rmeoved in 2001 (approx) and
replaced by gnome-python (though whether that one made py-gtk
packages or gnome-pytrhon packages I have no idea). The
latter seems to have been removed in 2005 sometime (if I read the cvs
log correctly). What, if anything, existed in Aug 2006 to
build this package I have no idea... I certainly cannot find
it. If the binary package would just tell me its origins,
all would be easy...
>Fix:
Add a little code to the code that builds binary packages,
and to pkg_info to report the value...
I know (believe, or perhaps hope) that pkgsrc is currently
being revised for other reasons, so I won't attempt to hack
this into the current sources and send a patch - consider this
a feature request for the next version.
Home |
Main Index |
Thread Index |
Old Index