Ports transitioned to git.

olli@ said:
… a tree of about 40k directories and 140k files. …
Click to expand...

For posterity/fun:

2021-04-07 08:34:51.png

– and so on.

Jose said:
unfortunately not documented, AFAIK.
Click to expand...

suntzu00 got it ☑ at https://forums.FreeBSD.org/threads/ports-transitioned-to-git.79598/post-504759 – it's documented in the main manual page for poudriere. Embarrassingly I hadn't thought to look there, because I (lazily) guessed that a URL would apply only in the context of creation of a ports tree. ¶ Thanks for replying, and for the other stuff.
 
grahamperrin said:
suntzu00 got it ☑ at https://forums.FreeBSD.org/threads/ports-transitioned-to-git.79598/post-504759 – it's documented in the main manual page for poudriere. Embarrassingly I hadn't thought to look there, because I (lazily) guessed that a URL would apply only in the context of creation of a ports tree. ¶ Thanks for replying, and for the other stuff.
Click to expand...
Where are you seeing it? I can't find -U in either poudriere(8) or poudriere-ports(8).

You're welcome!
 
Jose said:
Where are you seeing it?
Click to expand...
Sorry! I wasn't paying attention. My mistake, it's not in the main manual page, it's in a script. Here's the point at which it was added, a few years ago:

github.com

Level the ports git integration to the same level as jail · freebsd/poudriere@d547c13

Add a new argument -U to allow to to directly speficy the URL where to fetch the ports from Deprecate GIT_URL (but still use it in case already defined in poudriere.conf. Probably here we should no...
github.com github.com
 
Jose said:
Disclaimer: I'm trying to help you. Let me know if I'm annoying you instead and I'll shut up.
Click to expand...
I am not annoyed and I really appreciate your help getting a better understanding of how git works, which is quite different than what I am used to, coming from CVS and later SVN. I just don't feel that keeping my few additional patches in a local git branch would really make my life easier, at least not given my usual workflow that basically so far has been:
  1. make -C /usr/ports update fetchindex
  2. portmaster -a -d
And then repeat step 2 on every other machine that has the same ports tree mounted read-only via NFS.

Now after I made the switch to git not much has changed so far:
  1. git -C /usr/ports pull --ff-only
  2. portmaster -a -d
and again repeat step 2 on other machines. As I wrote in another thread, I decided to ditch the index and go without it, so I will not run make fetchindex anymore as part of my daily update routine. I could continue using make -C /usr/ports update which effectively does a git pull but I decided against that and defined an alias that includes the --ff-only flag and is more convenient to use, as I dont have to specify the directory manually.

You see the sole purpose of my local copy of the ports tree is to keep my machines updated. I don't use quarterly branches (in fact I never have), HEAD is the only thing I need, which is also why I decided to go with a shallow, single branch clone for the time being. The few additional files I keep in there were mostly born out of necessity and should that necessity cease to exist, I will more than happily remove those files as I generally prefer to have a clean tree. In some cases I almost forgot I put those files there long ago and running git status gives a quick overview of what files are there and where, that's fine by me.

git comes with substantial differences compared to CVS/SVN that are not easy to wrap your head around at first. But I guess it will get better once I start using git for my own pet projects or maybe even convert some of my repositories. So far I can say that I love the speed of git and the savings in disk space. I guess I will keep it ?
 
mickey said:
In some cases I almost forgot I put those files there long ago and running git status gives a quick overview of what files are there and where, that's fine by me.
Click to expand...
Sometimes, it helps more to have a commit message attached to them explaining why these files are there ;) At least, that's why I've been waiting to have the official ports on git for years, so I'm pretty happy right now, having a local log like this:
Code: 
334a65f5f620 (local) security/stunnel: downgrade to 5.48
4c6e5b95cd26 emulators/virtualbox-ose: fix build with libressl
8342e38e2f02 sysutils/gkrellm2: fix build with libressl
4e8215bada15 www/chromium: fix build with MIT krb5
[...]
25feb0d686a1 (origin/main, origin/HEAD, main) science/dlib-cpp and science/py-dlib: Update to 19.22
34a84984bcb2 net-p2p/xmrig: Update to 6.11.1

But yes, maybe it's easier after having played with git in some small repository created by yourself ;)
 
Everything working here now, thanks to all those who posted information on this.

I may migrate to using gitup though as that tool is for people like me who just want to check out the changes for maintaining the system, as on normal git I am not sure the best flags to use for this --ff-only etc.
 
Code: 
gitup -v 2 ports | grep descr | tee -a /tmp/472021-gitup.dat
Then, if that works as it does for me, the file at the top will have
+ pkg-descr which were added [ new ports, or revised ? ] which is
a functionality I was used to in svn.
It needs the latest working /usr/local/etc/gitup.conf though.
 
Feedback on performance, using baseline git (not yet tried gitup), its very quick, the slow part is making the index, would love make fetchindex to work on the quarterly branch. Or does it work now? as I see it mentioned a few posts up.
 
chrcol probably the best recommendation as of now is not to use an INDEX at all:
forums.freebsd.org

[ports][GIT][portsnap] Warning about INDEX

In the context of ports moving to GIT, as well as (expected) deprecation of portsnap, I've seen some questions regarding INDEX, which was automatically fetched by portsnap. Right now, I learned the following in an IRC channel full of devs: < XXXXXX> INDEX is currently dangerously misleading...
forums.freebsd.org forums.freebsd.org

What do you need it for?
 
I use portupgrade which needs it? (just tested now after your post to be sure, if it doesnt exist it does a make fetchindex which is bad as thats the HEAD version)

I have a script that runs each night after ports tree is updated and a command it runs to inform of which ports need updating seems to require the index as well.

I have now just altered my script though which is now able to detect if any updates were pulled over git, if none pulled it doesnt make a new index. So its not a huge problem.
 
I remember having read about several issues with portupgrade, don't remember the details. Yes, one of them is relying on INDEX. You should probably move away from that tool.

One possibility is portmaster. IMHO a lot better is a tool like either poudriere or synth.
 
Right now, it's already broken by the fact that it uses INDEX, which can't be generated correctly in presence of flavors (and, a lot of ports now use them). So, inevitably, it will occassionaly do the wrong thing. Don't complain afterwards.

I often see people refusing to change their workflow. Typically, something has to go badly wrong to change your mind. Well, you have been warned ;)
 
Zirias said:
Sometimes, it helps more to have a commit message attached to them explaining why these files are there
Click to expand...
I know exactly why these files are there. One removes a call to syscons from x11/nvidia-driver which causes it to fail if your kernel is built with vt(4) only, two files fix IPv6 prefix lifetimes in net/dhcp6, 4 files are additional patches to a specific port and the last is a custom build configuration for net/asterisk18 as generated by make menuselect. ?
Zirias said:
But yes, maybe it's easier after having played with git in some small repository created by yourself
Click to expand...
Certainly. Using a VCS to update src/ports is an entirely different thing from using it in active development.
Zirias said:
I remember having read about several issues with portupgrade, don't remember the details. Yes, one of them is relying on INDEX.
Click to expand...
If that hasn't changed in all those years, it depended on ruby (*yuk*) and used bdb to perform it's own housekeeping and also had a tendency to fail often. I'm really surprised anyone still uses it nowadays. Many years ago when I switched to ports-mgmt/portmaster it felt like I was one of the last to leave the sinking ship already.
richardtoohey2 said:
I use the index in
Code: 
pkg version -vIL=
Click to expand...
Use pkg version -vPL= and it will use the ports tree instead of the index file. You can also omit the option that specifies the method and it will automatically switch to using the ports tree in case an index file is not present: pkg version -vL=
 
Zirias said:
I remember having read about several issues with portupgrade, don't remember the details. Yes, one of them is relying on INDEX. You should probably move away from that tool.

One possibility is portmaster. IMHO a lot better is a tool like either poudriere or synth.
Click to expand...
In fact, I think that portmaster works better than portupgrade in general, not only because of the INDEX issue.
But YMMV, of course.
 
mickey said:
If that hasn't changed in all those years, it depended on ruby (*yuk*) and used bdb to perform it's own housekeeping and also had a tendency to fail often.
Click to expand...
I didn't have a problem with Ruby but the constant battling with a corrupt database made me seriously question my sanity. I was so happy when portmaster was released. Besides having no dependencies it worked much better than portupgrade ever did.
 
I just tried with git, well, actually gitup. It was very quick, so quick that I thought it hadn't worked. It doesn't make an INDEX, which messes up psearch, a package that I've used for years. I think a person who I was friends with on the old #freebsd irc, (before freenode, though I can't even remember which server--this was years ago), created it.

But aside from the lack of the INDEX file, it works quite well Usually, the only package I build from ports is dwm, because of some customization, so, I wouldn't notice too many other effects.
 
scottro said:
I just tried with git, well, actually gitup. It was very quick, so quick that I thought it hadn't worked. It doesn't make an INDEX, which messes up psearch, a package that I've used for years.
Click to expand...
I don’t know exactly what features psearch provides, but maybe Porgle is useful for you. It’s a web-based search engine for the FreeBSD ports collection. It has low browser requirements, it also works fine with text-based browsers (lynx, w3m, links).
 
You must log in or register to reply here.
Back
Top