Discussion:
Updating /usr/ports
Janos Dohanics
2021-05-24 16:40:23 UTC
Permalink
Hello,

The Handbook says "As needed, update /usr/ports after the initial Git
checkout:

# git -C /usr/ports pull"

[***@frigg ~]# portversion -v | grep -c "<"
[Reading data from pkg(8) ... - 294 packages found - done]
7

[***@frigg ~]# git -C /usr/ports pull
[...]
855 files changed, 8990 insertions(+), 7435 deletions(-)

[***@frigg ~]# portversion -v | grep -c "<"
[Reading data from pkg(8) ... - 294 packages found - done]
7

However, you also need to 'make index' which the Handbook does not mention:

[***@frigg /usr/ports]# make index

[***@frigg /usr/ports]# portversion -v | grep -c "<"
[Reading data from pkg(8) ... - 294 packages found - done]
[Updating the portsdb <format:bdb_btree> in /usr/ports ... - 31205 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.........21000.........22000.........23000.........24000.........25000.........26000.........27000.........28000.........29000.........30000.........31000.. ..... done]
12
--
Janos Dohanics
Kevin Oberman
2021-05-24 19:35:00 UTC
Permalink
Post by Janos Dohanics
Hello,
The Handbook says "As needed, update /usr/ports after the initial Git
# git -C /usr/ports pull"
[Reading data from pkg(8) ... - 294 packages found - done]
7
[...]
855 files changed, 8990 insertions(+), 7435 deletions(-)
[Reading data from pkg(8) ... - 294 packages found - done]
7
[Reading data from pkg(8) ... - 294 packages found - done]
[Updating the portsdb <format:bdb_btree> in /usr/ports ... - 31205 port
entries found
.........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.........21000.........22000.........23000.........24000.........25000.........26000.........27000.........28000.........29000.........30000.........31000..
..... done]
12
--
Janos Dohanics
If you don't mind being a couple of hours out of date, "make -C /usr/ports
feetchindex.". The index file is generated every 3 hours (I think), and
it's a lot faster than making it yourself.

Also, the grep is not needed. 'pkg version -vl<" (or, "-vL=" to catch
orphaned ports) will do the same thing. Don't worry if you are not using
ports. pkg does exactly the same things for both ports and packages except
for actually building ports. I thought that portversion was long gone. It's
not on either v12 or 13 on my systems.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: ***@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Janos Dohanics
2021-05-26 04:11:53 UTC
Permalink
On Mon, 24 May 2021 12:35:00 -0700
Post by Kevin Oberman
Post by Janos Dohanics
Hello,
The Handbook says "As needed, update /usr/ports after the initial
# git -C /usr/ports pull"
[Reading data from pkg(8) ... - 294 packages found - done]
7
[...]
855 files changed, 8990 insertions(+), 7435 deletions(-)
[Reading data from pkg(8) ... - 294 packages found - done]
7
[Reading data from pkg(8) ... - 294 packages found - done]
[Updating the portsdb <format:bdb_btree> in /usr/ports ... - 31205
port entries found
.........
1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.........21000.........22000.........23000.........24000.........25000.........26000.........27000.........28000.........29000.........30000.........31000.. .....
done] 12
--
Janos Dohanics
If you don't mind being a couple of hours out of date, "make
-C /usr/ports feetchindex.". The index file is generated every 3
hours (I think), and it's a lot faster than making it yourself.
Thanks, I know about 'make fetchindex' - this happens to be a
reasonably fast machine.

My point is though that 'git -C /usr/ports pull' apparently doesn't
update the port index, and the Handbook doesn't say you need to do
'make index' or 'make fetchindex'.

Also, 'portsnap fetch' && 'portsnap update' did update the index. My
reading of the Handbook was that 'git -C /usr/ports pull' alone gave
the same result as 'portsnap fetch' && 'portsnap update'.
Post by Kevin Oberman
Also, the grep is not needed. 'pkg version -vl<" (or, "-vL=" to catch
orphaned ports) will do the same thing. Don't worry if you are not
using ports. pkg does exactly the same things for both ports and
packages except for actually building ports. I thought that
portversion was long gone. It's not on either v12 or 13 on my systems.
My bad habit, thank you for the reminder!
--
Janos Dohanics
Kevin Oberman
2021-05-28 00:01:52 UTC
Permalink
Post by Janos Dohanics
On Mon, 24 May 2021 12:35:00 -0700
Post by Kevin Oberman
Post by Janos Dohanics
Hello,
The Handbook says "As needed, update /usr/ports after the initial
# git -C /usr/ports pull"
[Reading data from pkg(8) ... - 294 packages found - done]
7
[...]
855 files changed, 8990 insertions(+), 7435 deletions(-)
[Reading data from pkg(8) ... - 294 packages found - done]
7
[Reading data from pkg(8) ... - 294 packages found - done]
[Updating the portsdb <format:bdb_btree> in /usr/ports ... - 31205
port entries found
.........
1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.........21000.........22000.........23000.........24000.........25000.........26000.........27000.........28000.........29000.........30000.........31000..
.....
Post by Kevin Oberman
Post by Janos Dohanics
done] 12
--
Janos Dohanics
If you don't mind being a couple of hours out of date, "make
-C /usr/ports feetchindex.". The index file is generated every 3
hours (I think), and it's a lot faster than making it yourself.
Thanks, I know about 'make fetchindex' - this happens to be a
reasonably fast machine.
My point is though that 'git -C /usr/ports pull' apparently doesn't
update the port index, and the Handbook doesn't say you need to do
'make index' or 'make fetchindex'.
Also, 'portsnap fetch' && 'portsnap update' did update the index. My
reading of the Handbook was that 'git -C /usr/ports pull' alone gave
the same result as 'portsnap fetch' && 'portsnap update'.
Post by Kevin Oberman
Also, the grep is not needed. 'pkg version -vl<" (or, "-vL=" to catch
orphaned ports) will do the same thing. Don't worry if you are not
using ports. pkg does exactly the same things for both ports and
packages except for actually building ports. I thought that
portversion was long gone. It's not on either v12 or 13 on my systems.
My bad habit, thank you for the reminder!
--
Janos Dohanics
If you are trying to replace portsnap, I think the answer is net/gitup.
This only requires a single command, "gitup ports", and you get your index
updated along with updating all ports. I believe that the plan is to put
gitup into the base system fairly soon. I have not looked at whether
14-current has gitup, yet.

And, yes, it looks like the handbook needs some work as gitup is not yet
even mentioned. Like portsnap, gitup is for people who want to maintain an
up to date ports tree, but not good for developers. They do need to use git
and either generate the index or fetch it.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: ***@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
LuMiWa via freebsd-questions
2021-05-28 07:29:51 UTC
Permalink
On Thu, 27 May 2021 17:01:52 -0700
Post by Kevin Oberman
Post by Janos Dohanics
On Mon, 24 May 2021 12:35:00 -0700
On Mon, May 24, 2021 at 9:41 AM Janos Dohanics
Post by Janos Dohanics
Hello,
The Handbook says "As needed, update /usr/ports after the
# git -C /usr/ports pull"
[Reading data from pkg(8) ... - 294 packages found - done]
7
[...]
855 files changed, 8990 insertions(+), 7435 deletions(-)
[Reading data from pkg(8) ... - 294 packages found - done]
7
[Reading data from pkg(8) ... - 294 packages found - done]
[Updating the portsdb <format:bdb_btree> in /usr/ports ... -
31205 port entries found
.........
1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000.........17000.........18000.........19000.........20000.........21000.........22000.........23000.........24000.........25000.........26000.........27000.........28000.........29000.........30000.........31000..
.....
Post by Janos Dohanics
done] 12
--
Janos Dohanics
If you don't mind being a couple of hours out of date, "make
-C /usr/ports feetchindex.". The index file is generated every 3
hours (I think), and it's a lot faster than making it yourself.
Thanks, I know about 'make fetchindex' - this happens to be a
reasonably fast machine.
My point is though that 'git -C /usr/ports pull' apparently doesn't
update the port index, and the Handbook doesn't say you need to do
'make index' or 'make fetchindex'.
Also, 'portsnap fetch' && 'portsnap update' did update the index. My
reading of the Handbook was that 'git -C /usr/ports pull' alone gave
the same result as 'portsnap fetch' && 'portsnap update'.
Also, the grep is not needed. 'pkg version -vl<" (or, "-vL=" to
catch orphaned ports) will do the same thing. Don't worry if you
are not using ports. pkg does exactly the same things for both
ports and packages except for actually building ports. I thought
that portversion was long gone. It's not on either v12 or 13 on
my systems.
My bad habit, thank you for the reminder!
--
Janos Dohanics
If you are trying to replace portsnap, I think the answer is
net/gitup. This only requires a single command, "gitup ports", and
you get your index updated along with updating all ports. I believe
that the plan is to put gitup into the base system fairly soon. I
have not looked at whether 14-current has gitup, yet.
And, yes, it looks like the handbook needs some work as gitup is not
yet even mentioned. Like portsnap, gitup is for people who want to
maintain an up to date ports tree, but not good for developers. They
do need to use git and either generate the index or fetch it.
--
I am using "gitup ports" and it works without problem.
--
“Thinking is difficult, that’s why most people judge.”

Carl Jung
Jerry
2021-05-28 10:45:25 UTC
Permalink
Post by Kevin Oberman
If you are trying to replace portsnap, I think the answer is net/gitup.
This only requires a single command, "gitup ports", and you get your
index updated along with updating all ports. I believe that the plan
is to put gitup into the base system fairly soon. I have not looked at
whether 14-current has gitup, yet.
And, yes, it looks like the handbook needs some work as gitup is not
yet even mentioned. Like portsnap, gitup is for people who want to
maintain an up to date ports tree, but not good for developers. They
do need to use git and either generate the index or fetch it.
If "gitup" can fetch the "index" file, why can "git" not also
accomplish that feat? Is it a technical reason?

Asking for a friend.
--
Jerry

"A conclusion is the place where you got tired of thinking."
Kevin Oberman
2021-05-28 14:21:53 UTC
Permalink
Git was written by Linus for use as the Linux kernel. It knows nothing
about the FreeBSD specific index. getup is written for BSD with code that
understands FreeBSD and the ports system. It's also licensed with a BSD
license, not GPL.
Post by Jerry
Post by Kevin Oberman
If you are trying to replace portsnap, I think the answer is net/gitup.
This only requires a single command, "gitup ports", and you get your
index updated along with updating all ports. I believe that the plan
is to put gitup into the base system fairly soon. I have not looked at
whether 14-current has gitup, yet.
And, yes, it looks like the handbook needs some work as gitup is not
yet even mentioned. Like portsnap, gitup is for people who want to
maintain an up to date ports tree, but not good for developers. They
do need to use git and either generate the index or fetch it.
If "gitup" can fetch the "index" file, why can "git" not also
accomplish that feat? Is it a technical reason?
Asking for a friend.
--
Jerry
"A conclusion is the place where you got tired of thinking."
Janos Dohanics
2021-05-28 13:01:31 UTC
Permalink
On Thu, 27 May 2021 17:01:52 -0700
Post by Kevin Oberman
[...]
Post by Janos Dohanics
Also, 'portsnap fetch' && 'portsnap update' did update the index. My
reading of the Handbook was that 'git -C /usr/ports pull' alone gave
the same result as 'portsnap fetch' && 'portsnap update'.
Post by Kevin Oberman
Also, the grep is not needed. 'pkg version -vl<" (or, "-vL=" to
catch orphaned ports) will do the same thing. Don't worry if you
are not using ports. pkg does exactly the same things for both
ports and packages except for actually building ports. I thought
that portversion was long gone. It's not on either v12 or 13 on
my systems.
My bad habit, thank you for the reminder!
--
Janos Dohanics
If you are trying to replace portsnap, I think the answer is
net/gitup. This only requires a single command, "gitup ports", and
you get your index updated along with updating all ports. I believe
that the plan is to put gitup into the base system fairly soon. I
have not looked at whether 14-current has gitup, yet.
And, yes, it looks like the handbook needs some work as gitup is not
yet even mentioned. Like portsnap, gitup is for people who want to
maintain an up to date ports tree, but not good for developers. They
do need to use git and either generate the index or fetch it.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Thank you again.
--
Janos Dohanics
L***@lena.kiev.ua
2021-05-28 14:41:12 UTC
Permalink
Post by Kevin Oberman
If you are trying to replace portsnap, I think the answer is net/gitup.
This only requires a single command, "gitup ports", and you get your index
updated along with updating all ports.
No, `gitup ports` doesn't update index. It deletes INDEX-12 .
Kevin Oberman
2021-05-29 16:41:11 UTC
Permalink
Post by L***@lena.kiev.ua
Post by Kevin Oberman
If you are trying to replace portsnap, I think the answer is net/gitup.
This only requires a single command, "gitup ports", and you get your
index
Post by Kevin Oberman
updated along with updating all ports.
No, `gitup ports` doesn't update index. It deletes INDEX-12 .
Does "pkg version" use some other way of doing things than INDEX? I
checked a system that I recently upgraded to 13.0 and it lacks INDEX-13 (or
any INDEX-), but "pkg version -vL=" works fine. It is slower, though. It
was almost instantaneous and now takes about 45 seconds. Not sure whether
this is dependent on the number of installed ports. That system has only
about 325 ports installed. My development system has around a thousand, but
I use git and fetchindex there, so I can't easily compare.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: ***@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
LuMiWa via freebsd-questions
2021-05-29 21:23:15 UTC
Permalink
On Sat, 29 May 2021 09:41:11 -0700
Post by Kevin Oberman
Post by L***@lena.kiev.ua
Post by Kevin Oberman
If you are trying to replace portsnap, I think the answer is
net/gitup. This only requires a single command, "gitup ports",
and you get your
index
Post by Kevin Oberman
updated along with updating all ports.
No, `gitup ports` doesn't update index. It deletes INDEX-12 .
Does "pkg version" use some other way of doing things than INDEX? I
checked a system that I recently upgraded to 13.0 and it lacks
INDEX-13 (or any INDEX-), but "pkg version -vL=" works fine. It is
slower, though. It was almost instantaneous and now takes about 45
seconds. Not sure whether this is dependent on the number of
installed ports. That system has only about 325 ports installed. My
development system has around a thousand, but I use git and
fetchindex there, so I can't easily compare. --
Kevin Oberman, Part time kid herder and retired Network Engineer
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
/var/db/gitup/ports is updated every time as you use gitup ports. I
think it is an index. because when you run in /usr/ports make index are
those in /var/db/gitup updated.
--
“Thinking is difficult, that’s why most people judge.”

Carl Jung
RW via freebsd-questions
2021-05-29 22:20:45 UTC
Permalink
On Sat, 29 May 2021 09:41:11 -0700
Post by Kevin Oberman
Does "pkg version" use some other way of doing things than INDEX? I
checked a system that I recently upgraded to 13.0 and it lacks
INDEX-13 (or any INDEX-), but "pkg version -vL=" works fine. It is
slower, though. It was almost instantaneous and now takes about 45
seconds.
I was just reading the man page for pkg-version; by default the order
it tries is INDEX, ports tree, package repository.

This seems strange to me as I would have expected it to default to the
repository.
Kevin Oberman
2021-05-31 23:59:00 UTC
Permalink
On Sat, May 29, 2021 at 3:21 PM RW via freebsd-questions <
Post by LuMiWa via freebsd-questions
On Sat, 29 May 2021 09:41:11 -0700
Post by Kevin Oberman
Does "pkg version" use some other way of doing things than INDEX? I
checked a system that I recently upgraded to 13.0 and it lacks
INDEX-13 (or any INDEX-), but "pkg version -vL=" works fine. It is
slower, though. It was almost instantaneous and now takes about 45
seconds.
I was just reading the man page for pkg-version; by default the order
it tries is INDEX, ports tree, package repository.
This seems strange to me as I would have expected it to default to the
repository.
I would imagine that INDEX is preferred for speed. Milli-seconds vs
Many-seconds. Using repo is probably not a good way to go as people
maintaining a local ports tree are likely to build ports where the repo
could be days behind the tree. I have seen the builders take over four days
to run a large update and as much as 4 days to update all of the mirrors.
That is about a week and there can be a LOT of updates in a week. Makes
maintaining a local tree a bit less desirable. ports tree is dog slow
compared to INDEX and probably repo, but it is reliable and always in sync
with the current local copy of the tree. On a system with 1500 or so ports
installed, if it is done as I guess it is, this would take a while, though
still not as long as building INDEX locally as it would only care about
installed ports.

The above is based on behavior of things and may be wrong.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: ***@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
RW via freebsd-questions
2021-06-01 13:25:51 UTC
Permalink
On Mon, 31 May 2021 16:59:00 -0700
Post by Kevin Oberman
On Sat, May 29, 2021 at 3:21 PM RW via freebsd-questions <
Post by RW via freebsd-questions
I was just reading the man page for pkg-version; by default the
order it tries is INDEX, ports tree, package repository.
This seems strange to me as I would have expected it to default to
the repository.
Using repo is probably not a good way to go as people
maintaining a local ports tree are likely to build ports where the
repo could be days behind the tree.
Having a ports tree doesn't necessarily mean that that you build
mainly from ports. I keep it around for information, and to build one
port with patches. More importantly, a new user might install the tree
out of curiosity, but use the repository.

IMO the natural assumption is that a package tool compares versions
with the repository, not that it changes its default based on a guess
about what you are trying to do.
Matthew Seaman
2021-06-06 22:45:25 UTC
Permalink
Post by RW via freebsd-questions
I was just reading the man page for pkg-version; by default the order
it tries is INDEX, ports tree, package repository.
This seems strange to me as I would have expected it to default to the
repository.
That is spelled:

pkg version -vRL=

Cheers,

Matthew

Loading...