Hi Jeremy, hi Marc, Jeremy Evans wrote on Wed, Sep 19, 2007 at 09:19:34AM -0700: > On 9/19/07, Marc Espie <[EMAIL PROTECTED]> wrote: >> On Tue, Sep 18, 2007 at 10:50:37PM +0200, Ingo Schwarze wrote:
>>> I'm running -current, installing most of my packages from snapshot >>> mirrors. But i'm also frequently building ports myself, mostly >>> testing submissions to ports@, but also building some i hacked up >>> myself. >>> >>> Now, if i put the snapshot-mirror before my own packages in PKG_PATH, >>> what i modified in mystuff/ will only get installed by manually typing >>> pkg_add -r, and even worse, it will get overwritten during the next >>> pkg_add -ui. >>> >>> On the other hand, if i put the snapshot-mirror after my own packages >>> in PKG_PATH, then my home-grown packages will never get updated to >>> officially committed versions later. In particular, i will not even >>> realize that new official packages have been uploaded to the >>> snapshot mirror, unless i manually check for them on a package-by- >>> package basis. >>> >>> I must admin i'm a bit at a loss now... >>> >>> For this particular situation, the old pkg_add search logic - >>> i.e. reading and merging all repository listings and selecting >>> the newest package from the combined list - seems to have worked >>> better for me. :-/ >> >> With the old scheme, this meant you had to make choices for a lot >> of packages in interactive mode. This is true. With the amount of packages i am using, it takes a few minutes to check off these questions, but that's viable in my case. >> We do need to have better (smarter) version comparison before >> bringing in such a mechanism back. Something along the lines of defining a few names for common numbering schemes (e.g. "d.d.d" and "d.d" for three-part and two-part dotted-decimal numbering, respectively), putting these into /var/db/*/+NUMBERING? Even if only the obvious cases are classified in such a way and special cases like "jpeg", "ircII" and "links" are left unresolved, this would solve most of the practical problems. You would no more need to wade through long lists of questions. Pure heuristics are probably not good enough. Even if wild guesses would match nearly all cases, those few where guessing goes wrong might get really annoying. Alternatively, one could try to pick the d.d, d.d.d, d.d.d.d numbering schemes by heuristics and only marks those (few) ports where these schemes lead astray. Do you think hacking up a proof-of-concept implementation for either of these ideas might make sense, or do you plan to implement a completely different algorithm? >> I'm afraid that building home-grown versions of ports + using >> snapshots is going to require hand-holding in any case, because >> of the differences in library versions, or the seemingly downgrade >> of some stuff when it finally gets committed. >> >> What you have is an interesting issue. If you want `automated' >> handling, it has no easy solution... Well, i'm prepared to deal with occasional breakage with respect to libraries by hand, and nothing is _fully_ automatic anyway as soon as you start building your own, uncommitted ports. Jeremy Evans wrote on Wed, Sep 19, 2007 at 09:19:34AM -0700: > PKG_CACHE=/usr/ports/packages/amd64/all/ > PKG_PATH=ftp://rt.fm/pub/OpenBSD/4.1/packages/amd64/ pkg_add -n "$@" Combining PKG_CACHE with -n is a really smart workaround that didn't occur to me yet. Thanks for pointing that out! I tested this and it works well. Quite probably, i will use this until someone invents something even better. Yours, Ingo
