On Tue, Sep 18, 2007 at 10:50:37PM +0200, Ingo Schwarze wrote: > Hi Marc, > > Marc Espie wrote on Sun, Aug 26, 2007: > > > The specific issue of a long PKG_PATH was solved somewhere > > between 4.1 and 4.2. > > pkg_add(1) now stops at the first path element with valid candidates. > > Do you have any tips for the following scenario, which i suspect > might not even be uncommon: > > 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. We do need to have better (smarter) version comparison before bringing in such a mechanism back. 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...
