Don't overwrite /usr/local/etc/pkg/repos/FreeBSD.conf

[cndghm]

As addressed by Bug 291501 and Bug 291502.

The append redirection operator can be used since the first time because if the user is using pkgbase, the file /usr/local/etc/pkg/repos/FreeBSD.conf already exists.

[github-actions[bot]]

Thank you for taking the time to contribute to FreeBSD! All issues resolved.

[grahamperrin]

… Bug 291501 and Bug 291502. …

Thanks; 291502 will need a change to the doc tree.

[cndghm]

I have updated the commit, removing the 'file' word in line 4, thanks for the review. I will make an pull request about Bug 291502.

[concussious]

I'm not sure if I understand, We do want to overwrite it if it exists because if the old repo is there, it will conflict, right?

[cndghm]

@concussious Since 15.0 introduced pkgbase, the file in /usr/local/etc/pkg/repos/FreeBSD.conf existis by default (if the user selected tech preview in the install process) and to be exact the file contains FreeBSD-base: { enable: yes } which will allow the user to get updates trough pkg. If we overwrite it will disable the FreeBSD-base repo.

Of course, if the user didn't choose pkgbase the >> operator will create an file the same way, the only diferrence is that as I said in the first paragraph is that if the file exists, it only append.

Edit: I'm not sure if the comment on line 9 is still relevant, maybe when/if pkgbase becomes the default it should be removed.

Edit: I just noticed that the other FreeBSD.conf.latest and FreeBSD.conf.quaterly-release also has the same comment. If we agree that this is the better option I will edit those files in this PR also.

[jrtc27]

If you're changing one of these files you should change all of them to match, the header is copied between them

[grahamperrin]

I'm not sure if I understand, We do want to overwrite …

Simply: with pkgbase, it's unwanted, because the system will cease to gain fixes for errata and security.

[grahamperrin]

cndghm requested a review from grahamperrin

I don't see an option to approve, but I think the changes to the three files are fairly non-contentious.

Thanks!

---

Commit log message nits:

• the first line should ideally mention /usr/local/etc/pkg/repos/FreeBSD.conf instead of /usr/local/etc/pkg/repos
• subsequent lines should have a maximum length (not wrap as they currently do).

I can't remember the exact guidance, but character limits might be 50 for the first line, 72 for subsequent lines.

49 characters (food for thought):

Comments: FreeBSD.conf should not be overwritten

[cndghm]

I will make those changes and make another commit here and send the patch on bugzilla, thank you for your guidance.

Edit: You are right about mentioning FreeBSD.conf, my mistake

[concussious]

send the patch on bugzilla

No please, the patch is in the right place. Bugzilla is the most inconvenient place for us to receive patches. It literally has no mechanism for code review. Who keeps saying to do that?

[concussious]

The closing was an accidental fat fingering, apologies.

[cndghm]

send the patch on bugzilla

No please, the patch is in the right place. Bugzilla is the most inconvenient place for us to receive patches. It literally has no mechanism for code review. Who keeps saying to do that?

A lot of people, but I would upstream the changes to GitHub also. Don't worry.

[concussious]

A lot of people,

Who are those people? They need to be kindly updated on the information.

but I would upstream the changes to GitHub also.

No, that is wrong because it duplicates work and makes a mess of the paper trail. From CONTRIBUTING.Md, paragraph four:

"A change should be submitted by only one method. For example, please do not open a GitHub pull request and create a Phabricator review for the same change (unless explicitly requested to do so by a FreeBSD committer)."

Don't worry

As a maintainer it is my job to worry :)

[cndghm]

A lot of people,

Who are those people? They need to be kindly updated on the information.

I'm new to contributing to FreeBSD so, i though I would need some information, I have read the CONTRIBUTING.Md as you said above but also by people chatting on Discord. One of the discussions where about how the ways FreeBSD is currently accepting patches is splitted across multiple platforms one advice I read was that sending on bugzilla was also good (something that I don't quite remember why, but I think it was because most of the maintainers did read more bugzilla)

but I would upstream the changes to GitHub also.

No, that is wrong because it duplicates work and makes a mess of the paper trail. From CONTRIBUTING.Md, paragraph four:

"A change should be submitted by only one method. For example, please do not open a GitHub pull request and create a Phabricator review for the same change (unless explicitly requested to do so by a FreeBSD committer)."

Don't worry

As a maintainer it is my job to worry :)

That being said, I will follow what you said. I did in fact choose this small "problem" because I was aware of how things could become messy. I apologize for that. I will keep the changes here then. Thank you!

[concussious]

people chatting on Discord.

Can you please share the project policy with them if you go back there? It creates extra work and confusion if the patch is multiple places. That discord server is unaffiliated with the project and is not run by project members. See: https://wiki.freebsd.org/Discord/DiscordServer

I apologize for that

No need to apologize. The fragmentation creates these problems for all of us. Thank you for your attention to these details and your submission.

[cndghm]

Sure! I'm make a comment about the current guidelines next time I go to the Discord Server. Didn't know it was unofficial.