Hi Jacob, Jacob Meuser wrote on Thu, Mar 13, 2008 at 02:14:27AM +0000: > On Thu, Mar 13, 2008 at 01:59:56AM +0100, Ingo Schwarze wrote: >> On Tuesday 11 March 2008 17:53:50 Jacob Meuser wrote:
>>> I _hate_ it when I change a port locally and up the p level, >>> and then pkg_add -u downgrades that package. >> >> Hmmm, the p-level is not ideal for keeping track of private tweaks, >> imho it's better reserved for official, committed patch levels. > > why? Because using the same thing for two different purposes provokes clashes, in this case consider the following example: * You start from the committed version _op1. * You implement private tweaks _op2 and _op3. * The maintainer commits _op2. * Your pkg_add now has a hard time figuring out whether _op3 or _op2 is more recent. Still worse, in fact, neither _op3(local) nor _op2(official) are up to date: You will probably want to merge official and private patches first. How is pkg_add going to figure that out? Then, how will you call the result of your private merge? It's the successor to _op2(official), so _op3? Or it's the successor to _op3(local), so _op4? Probably, even though my suggestion does look more complicated on first sight, it might turn out to be simpler, in the sense of less confusing: * You start from the committed version p1. * You implement private tweaks p1u0 and p1u1 - now you even see which committed version this is all based on, and you are reminded to consider submitting your changes upstream or to the maintainer, in case they prove useful and stable. * The maintainer commits p2. * Your pkg_add asks you to choose either p1u1 or p2 - nicely reminding you that you might want to merge. * You build p2u1, and pkg_add upgrades without any further questions. > so now there's p, v and u? I though the main impetus of OpenBSD > was to make reliable by keeping them simple? [...] > why is there not just a single package version variable tied to > pkgpath? always increments with each package change regardles > of new version or just a change or a revert I don't see how this might reduce the danger of accidentally downgrading locally changed ports. But it does indeed seem to have merit as an alternative to the p#v# scheme. PRO _op#: - always exactly one number; in particular, never two - avoids more and more ports getting v# tagged on over time - no parsing of the upstream version - calling "_op#" just "p#" would make the transition trivial PRO p#v#: - after upstream bumps, not even one additional number is needed - avoids arriving at vim-9.3.273_op148 in the long run I'm not the one to choose either scheme - but imho both schemes could profit from an additional u-level. Yours, Ingo
