Skip to content

Conversation

@cndghm
Copy link

@cndghm cndghm commented Dec 13, 2025

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
Copy link

github-actions bot commented Dec 13, 2025

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

@grahamperrin
Copy link
Contributor

Bug 291501 and Bug 291502. …

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

@cndghm
Copy link
Author

cndghm commented Dec 14, 2025

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.

@cndghm cndghm requested a review from grahamperrin December 14, 2025 21:30
@concussious
Copy link
Contributor

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
Copy link
Author

cndghm commented Dec 15, 2025

@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
Copy link
Contributor

jrtc27 commented Dec 15, 2025

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

@grahamperrin
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

cndghm commented Dec 21, 2025

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
Copy link
Contributor

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 concussious reopened this Dec 21, 2025
@concussious
Copy link
Contributor

The closing was an accidental fat fingering, apologies.

@cndghm
Copy link
Author

cndghm commented Dec 21, 2025

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
Copy link
Contributor

concussious commented Dec 21, 2025

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
Copy link
Author

cndghm commented Dec 21, 2025

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!

The files /usr/sbin/pkg/FreeBSD.conf.* currently set base repo to {enable: no}.
We don't want to overwrite /local/etc/pkg/repos/FreeBSD.conf that already exists
when users choose tech preview in the installation.

Signed-off-by: Guilherme Augusto de Souza Candinho <cndghm@gmail.com>
@concussious
Copy link
Contributor

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
Copy link
Author

cndghm commented Dec 21, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants