SOLVED: pkg version mismatch [succeeds port...]

Jeffrey Bouquet jeffreybouquet at yahoo.com
Tue Jun 2 03:44:27 UTC 2015



On 06/01/15 13:44, Lowell Gilbert wrote:
> [pkg@ snipped, because it's irrelevant]
>
> Jeffrey Bouquet via freebsd-ports <freebsd-ports at freebsd.org> writes:
>
>> I noticed the ports tree here had net/uget 1.10.4_1 even after "svn up"... while
>> pkg upgrading installed 2.0.  "pkg version" (one of 3 ways) reported 
>> "succeeds port"... was about to post a question about pkg, but it can be fixed
>> by 
>>
>> cd /usr/ports/net/uget
>> svn revert . -R 
>>
>> [found at stackoverflow]
>>
>> [I've about thirty of so of those directories to fix up, for installed ports... it seems].
>>
>> Wondering if the fix can be put in CAVEATS or something in the pkg version
>> man page... "for those using subversion..." 
>>
>> also if ever a man page with many examples is crafted for subversion on FreeBSD,
>> that could be one of them.
>>
>> Others:
>>
>> cd /usr/ports
>> svn resolve .
> These would not be useful to document unless you can document how you
> got into those situations in the first place. 

I think it was disk failure and svn did not like resuming the updates to the
directories newly crafted into a everyday install type system from backup.
[ I prefer keeping the same tree across years of updates because I am used
to saving build logs, .htm and .msg and .txt hint files, etc within the
directories. ... for easier reference]
> "svn revert" is only
> necessary if you made local changes to the sources under svn control,
I typically use it to build, ports, say, that are broken due to no fetch
possible, for
which I already have the sources, so I can "svn revert Makefile" and
similar uses.

> and even then usually if svn can't automatically merge upstream changes
> into yours. "svn resolve" is the way to sort out the merge if svn can't
> do it.
Just a few days ago I used "svn resolve" to tune the ports tree.  Maybe the
side effects of that, and/or the response I type to the svn questions
(always TC, always
r, for those familiar with the two types...text and tree, respetively)
are what causes the version mismatches
that were present. [  OR the situation in the first paragraph above. ]

Part of  a daily svn log:

............................................................................
 
Updating 'usr/ports':
......................... [snipped]
 Summary of conflicts:
Text conflicts: 0 remaining (and 2 already resolved)
Tree conflicts: 0 remaining (and 2 already resolved)
..................................................................................................................


     I tend to annotate uses into hint files (.txt .msg .dat .how .htm)
in /usr/src RE svn
Has saved a ports tree from newly needing to be downloaded more than once
>
> It sounds like you're not intending to make local changes at all. In
> that case, I'd recommend you use something else (probably portsnap) to
> maintain your ports tree.
I think, am not sure, that portsnap and svn are the only two. I prefer
the more cvs-like workings
of svn, and have never used portsnap...  I think the former enables one more
fine-grained tuning unless one knows the workings of the latter.  I
could be wrong
but...


Just information for the list... as a followup.  Not wanting to prolong
the thread without
reason.....



> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"



More information about the freebsd-ports mailing list