Gitlab cannot support an undocumented set of Git repository names. Currently, this list appears to contain at least these names:
badges blame blob builds commits create create_dir edit files find_file new preview raw refs tree update wikis
There may be additional constraints for:
environments gitlab-lfs info
We have at least one collision today, tree.
One way to avoid these problems is to prefix all package names with “pkg-”. This way, future collisions become extremely unlikely, at the cost of a one-time large rename.
The alternative would be to main an exception mechanism for colliding package names such as “tree”. This has been the current approach, but as far as I can tell, it is not working.
Implementing this change depends on the completion of the package removal process because it does not appear worthwhile to rename packages which no longer exist in the distribution.
Thanks, Florian
On Tue, Aug 31, 2021 at 7:35 AM Florian Weimer fweimer@redhat.com wrote:
Gitlab cannot support an undocumented set of Git repository names. Currently, this list appears to contain at least these names:
badges blame blob builds commits create create_dir edit files find_file new preview raw refs tree update wikisThere may be additional constraints for:
environments gitlab-lfs infoWe have at least one collision today, tree.
One way to avoid these problems is to prefix all package names with “pkg-”. This way, future collisions become extremely unlikely, at the cost of a one-time large rename.
Are you suggesting this for all packages in Stream, or just the subset that conflicts with Gitlab reserved names?
josh
The alternative would be to main an exception mechanism for colliding package names such as “tree”. This has been the current approach, but as far as I can tell, it is not working.
Implementing this change depends on the completion of the package removal process because it does not appear worthwhile to rename packages which no longer exist in the distribution.
Thanks, Florian
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
* Josh Boyer:
On Tue, Aug 31, 2021 at 7:35 AM Florian Weimer fweimer@redhat.com wrote:
Gitlab cannot support an undocumented set of Git repository names. Currently, this list appears to contain at least these names:
badges blame blob builds commits create create_dir edit files find_file new preview raw refs tree update wikisThere may be additional constraints for:
environments gitlab-lfs infoWe have at least one collision today, tree.
One way to avoid these problems is to prefix all package names with “pkg-”. This way, future collisions become extremely unlikely, at the cost of a one-time large rename.
Are you suggesting this for all packages in Stream, or just the subset that conflicts with Gitlab reserved names?
The only way to get rid of the exceptions is to do it for all packages.
Thanks, Florian
This seems extreme for one package named "tree", when Pagure's web UI has a similar bug https://pagure.io/pagure/issue/4409
What if we just set the policy to "If your package is on the list of names at https://docs.gitlab.com/ee/user/reserved_names.html , add a "-pkg" suffix" ?
Does the GitLab support contract cover this sort of thing?
- Ken
On Tue, Aug 31, 2021 at 7:35 AM Florian Weimer fweimer@redhat.com wrote:
Gitlab cannot support an undocumented set of Git repository names. Currently, this list appears to contain at least these names:
badges blame blob builds commits create create_dir edit files find_file new preview raw refs tree update wikisThere may be additional constraints for:
environments gitlab-lfs infoWe have at least one collision today, tree.
One way to avoid these problems is to prefix all package names with “pkg-”. This way, future collisions become extremely unlikely, at the cost of a one-time large rename.
The alternative would be to main an exception mechanism for colliding package names such as “tree”. This has been the current approach, but as far as I can tell, it is not working.
Implementing this change depends on the completion of the package removal process because it does not appear worthwhile to rename packages which no longer exist in the distribution.
Thanks, Florian
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
For consistency, I'd prefer a uniform prefix so we don't have to maintain a list of exceptions.... and then have a way to export this easily to downstream tooling.
Bikeshed moment:
pkg- rpm- src-
Pat
On Tue, 2021-08-31 at 10:11 -0400, Ken Dreyer wrote:
This seems extreme for one package named "tree", when Pagure's web UI has a similar bug https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_pagure_issue_...
What if we just set the policy to "If your package is on the list of names at https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.gitlab.com_ee_user... , add a "-pkg" suffix" ?
Does the GitLab support contract cover this sort of thing?
- Ken
On Tue, Aug 31, 2021 at 7:35 AM Florian Weimer fweimer@redhat.com wrote:
Gitlab cannot support an undocumented set of Git repository names. Currently, this list appears to contain at least these names:
badges blame blob builds commits create create_dir edit files find_file new preview raw refs tree update wikis
There may be additional constraints for:
environments gitlab-lfs info
We have at least one collision today, tree.
One way to avoid these problems is to prefix all package names with “pkg-”. This way, future collisions become extremely unlikely, at the cost of a one-time large rename.
The alternative would be to main an exception mechanism for colliding package names such as “tree”. This has been the current approach, but as far as I can tell, it is not working.
Implementing this change depends on the completion of the package removal process because it does not appear worthwhile to rename packages which no longer exist in the distribution.
Thanks, Florian
CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
On Tue, Aug 31, 2021, at 11:13, Patrick Riehecky wrote:
For consistency, I'd prefer a uniform prefix so we don't have to maintain a list of exceptions.... and then have a way to export this easily to downstream tooling.
Bikeshed moment:
pkg- rpm- src-
Pat
On Tue, 2021-08-31 at 10:11 -0400, Ken Dreyer wrote:
This seems extreme for one package named "tree", when Pagure's web UI has a similar bug https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_pagure_issue_...
What if we just set the policy to "If your package is on the list of names at https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.gitlab.com_ee_user... , add a "-pkg" suffix" ?
Does the GitLab support contract cover this sort of thing?
- Ken
On Tue, Aug 31, 2021 at 7:35 AM Florian Weimer fweimer@redhat.com wrote:
Gitlab cannot support an undocumented set of Git repository names. Currently, this list appears to contain at least these names:
badges blame blob builds commits create create_dir edit files find_file new preview raw refs tree update wikis
There may be additional constraints for:
environments gitlab-lfs info
We have at least one collision today, tree.
One way to avoid these problems is to prefix all package names with “pkg-”. This way, future collisions become extremely unlikely, at the cost of a one-time large rename.
The alternative would be to main an exception mechanism for colliding package names such as “tree”. This has been the current approach, but as far as I can tell, it is not working.
Implementing this change depends on the completion of the package removal process because it does not appear worthwhile to rename packages which no longer exist in the distribution.
Thanks, Florian
CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
CentOS-devel mailing list CentOS-devel@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
There is a ton of tooling that relies on the repo naming that we have right now, and maintainers are actively working against the naming conventions we have. Itmakes sense to have a convention for the very very few packages affected here, but we shouldn't apply that to the entirety of dist-git just because of infra problems with a handful of package names.
--Brian
* Brian Stinson:
There is a ton of tooling that relies on the repo naming that we have right now, and maintainers are actively working against the naming conventions we have. Itmakes sense to have a convention for the very very few packages affected here, but we shouldn't apply that to the entirety of dist-git just because of infra problems with a handful of package names.
The bulk rename would force everyone to get their tooling in order. I'm pretty sure it's the only way to fix the “tree” problem everywhere. Otherwise, people say “I'll deal with that manually” or “we're just going to add that special case”. But in too many cases, neither happens, and it just remains unfixed indefintely. And never get out of a bad state.
Thanks, Florian
On Tue, Aug 31, 2021, at 12:19, Florian Weimer wrote:
- Brian Stinson:
There is a ton of tooling that relies on the repo naming that we have right now, and maintainers are actively working against the naming conventions we have. Itmakes sense to have a convention for the very very few packages affected here, but we shouldn't apply that to the entirety of dist-git just because of infra problems with a handful of package names.
The bulk rename would force everyone to get their tooling in order. I'm pretty sure it's the only way to fix the “tree” problem everywhere. Otherwise, people say “I'll deal with that manually” or “we're just going to add that special case”. But in too many cases, neither happens, and it just remains unfixed indefintely. And never get out of a bad state.
Thanks, Florian
"force everyone to get their tooling in order" and disrupt hundreds of folks doing regular development for how long?
Solving this by asking a very small number maintainers to adjust their repo names seems a much better use of time and effort here.
--Brian
* Brian Stinson:
On Tue, Aug 31, 2021, at 12:19, Florian Weimer wrote:
- Brian Stinson:
There is a ton of tooling that relies on the repo naming that we have right now, and maintainers are actively working against the naming conventions we have. Itmakes sense to have a convention for the very very few packages affected here, but we shouldn't apply that to the entirety of dist-git just because of infra problems with a handful of package names.
The bulk rename would force everyone to get their tooling in order. I'm pretty sure it's the only way to fix the “tree” problem everywhere. Otherwise, people say “I'll deal with that manually” or “we're just going to add that special case”. But in too many cases, neither happens, and it just remains unfixed indefintely. And never get out of a bad state.
Thanks, Florian
"force everyone to get their tooling in order" and disrupt hundreds of folks doing regular development for how long?
Gitlab has a repository aliasing mechanism. It could be a gradual transition for existing packages.
Thanks, Florian
On Tue, Aug 31, 2021 at 1:34 PM Florian Weimer fweimer@redhat.com wrote:
- Brian Stinson:
On Tue, Aug 31, 2021, at 12:19, Florian Weimer wrote:
- Brian Stinson:
There is a ton of tooling that relies on the repo naming that we have right now, and maintainers are actively working against the naming conventions we have. Itmakes sense to have a convention for the very very few packages affected here, but we shouldn't apply that to the entirety of dist-git just because of infra problems with a handful of package names.
The bulk rename would force everyone to get their tooling in order. I'm pretty sure it's the only way to fix the “tree” problem everywhere. Otherwise, people say “I'll deal with that manually” or “we're just going to add that special case”. But in too many cases, neither happens, and it just remains unfixed indefintely. And never get out of a bad state.
Thanks, Florian
"force everyone to get their tooling in order" and disrupt hundreds of folks doing regular development for how long?
Gitlab has a repository aliasing mechanism. It could be a gradual transition for existing packages.
No. This is extremely excessive. We already have namespaces, and the list of reserved names is already known. Of that list, there is a single one today that actually has an RPM that overlaps. Adding content to RHEL is not a wild west process, so we can control what our SRPMs are named as they are added going forward.
We are not going to rename every package to fix one, particularly when we can simply say "no" to any future conflicts.
josh
* Josh Boyer:
Gitlab has a repository aliasing mechanism. It could be a gradual transition for existing packages.
No. This is extremely excessive. We already have namespaces, and the list of reserved names is already known. Of that list, there is a single one today that actually has an RPM that overlaps. Adding content to RHEL is not a wild west process, so we can control what our SRPMs are named as they are added going forward.
Okay, so the prefix isn't going to fly. The “+” problem is also more widespread, and the prefix does not solve that at all.
I checked the package addition process, and it actually flows through CentOS these days (“centpkg import” is used), so it should prevent the recurrence of the “tree” problem. Unlike other parts of the tooling, centpkg seems to know about the “+” rewriting (to “plus”), so that's not going to help us to prevent future mistakes in that area, though.
What should we do here? We have a couple of packages that are basically impossible to maintain in the present state in CentOS Stream.
One possible way forward could be:
* Rename the tree package (starting with Fedora). * Rename all packages with + in their names (also in Fedora). * Ban + in future source package names. * For every REPO, the RPM spec file must be called REPO.spec, and the source RPM name must be REPO.
I'm not sure how good RPM is at source package renaming, though. If the repository name and the .spec file name and source package name differ (due to the “+” rewriting or the dump/restore thing), we end up with tooling issues again (like we had with dump/restore). If we rename the package outright, it affects the binary packages as well, and might need an exception at this point.
My worry is that people have been saying “we'll deal with these few exceptions manually”, but as far as I can tell, that is just not what's happening. RPM components that should be trivially to maintain are suddenly very difficult.
Thanks, Florian
On Wed, Sep 1, 2021, at 10:32, Florian Weimer wrote:
- Josh Boyer:
Gitlab has a repository aliasing mechanism. It could be a gradual transition for existing packages.
No. This is extremely excessive. We already have namespaces, and the list of reserved names is already known. Of that list, there is a single one today that actually has an RPM that overlaps. Adding content to RHEL is not a wild west process, so we can control what our SRPMs are named as they are added going forward.
Okay, so the prefix isn't going to fly. The “+” problem is also more widespread, and the prefix does not solve that at all.
I checked the package addition process, and it actually flows through CentOS these days (“centpkg import” is used), so it should prevent the recurrence of the “tree” problem. Unlike other parts of the tooling, centpkg seems to know about the “+” rewriting (to “plus”), so that's not going to help us to prevent future mistakes in that area, though.
What should we do here? We have a couple of packages that are basically impossible to maintain in the present state in CentOS Stream.
One possible way forward could be:
- Rename the tree package (starting with Fedora).
- Rename all packages with + in their names (also in Fedora).
- Ban + in future source package names.
- For every REPO, the RPM spec file must be called REPO.spec, and the source RPM name must be REPO.
I'm not sure how good RPM is at source package renaming, though. If the repository name and the .spec file name and source package name differ (due to the “+” rewriting or the dump/restore thing), we end up with tooling issues again (like we had with dump/restore). If we rename the package outright, it affects the binary packages as well, and might need an exception at this point.
My worry is that people have been saying “we'll deal with these few exceptions manually”, but as far as I can tell, that is just not what's happening. RPM components that should be trivially to maintain are suddenly very difficult.
Thanks, Florian
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
We should consider renaming the tree repository in Fedora and CentOS Stream/RHEL, and leave the + packages alone. We've asked for fixes in gitlab to support the proper naming including '+' characters.
There are other source packages that don't match 1:1 with their dist-git repositories, so I'm not sure how much trouble a hard requirement would cause.
--Brian
On Wed, Sep 1, 2021 at 11:44 AM Brian Stinson brian@bstinson.com wrote:
On Wed, Sep 1, 2021, at 10:32, Florian Weimer wrote:
- Josh Boyer:
Gitlab has a repository aliasing mechanism. It could be a gradual transition for existing packages.
No. This is extremely excessive. We already have namespaces, and the list of reserved names is already known. Of that list, there is a single one today that actually has an RPM that overlaps. Adding content to RHEL is not a wild west process, so we can control what our SRPMs are named as they are added going forward.
Okay, so the prefix isn't going to fly. The “+” problem is also more widespread, and the prefix does not solve that at all.
I checked the package addition process, and it actually flows through CentOS these days (“centpkg import” is used), so it should prevent the recurrence of the “tree” problem. Unlike other parts of the tooling, centpkg seems to know about the “+” rewriting (to “plus”), so that's not going to help us to prevent future mistakes in that area, though.
What should we do here? We have a couple of packages that are basically impossible to maintain in the present state in CentOS Stream.
One possible way forward could be:
- Rename the tree package (starting with Fedora).
- Rename all packages with + in their names (also in Fedora).
- Ban + in future source package names.
- For every REPO, the RPM spec file must be called REPO.spec, and the source RPM name must be REPO.
I'm not sure how good RPM is at source package renaming, though. If the repository name and the .spec file name and source package name differ (due to the “+” rewriting or the dump/restore thing), we end up with tooling issues again (like we had with dump/restore). If we rename the package outright, it affects the binary packages as well, and might need an exception at this point.
My worry is that people have been saying “we'll deal with these few exceptions manually”, but as far as I can tell, that is just not what's happening. RPM components that should be trivially to maintain are suddenly very difficult.
Thanks, Florian
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
We should consider renaming the tree repository in Fedora and CentOS Stream/RHEL, and leave the + packages alone. We've asked for fixes in gitlab to support the proper naming including '+' characters.
There are other source packages that don't match 1:1 with their dist-git repositories, so I'm not sure how much trouble a hard requirement would cause.
At least for pagure, it might be worth changing the slug from /tree/ to /filelist/ for 6.0 so that this isn't a problem anymore for the "tree" package...
On Wed, Sep 1, 2021, at 10:53, Neal Gompa wrote:
On Wed, Sep 1, 2021 at 11:44 AM Brian Stinson brian@bstinson.com wrote:
On Wed, Sep 1, 2021, at 10:32, Florian Weimer wrote:
- Josh Boyer:
Gitlab has a repository aliasing mechanism. It could be a gradual transition for existing packages.
No. This is extremely excessive. We already have namespaces, and the list of reserved names is already known. Of that list, there is a single one today that actually has an RPM that overlaps. Adding content to RHEL is not a wild west process, so we can control what our SRPMs are named as they are added going forward.
Okay, so the prefix isn't going to fly. The “+” problem is also more widespread, and the prefix does not solve that at all.
I checked the package addition process, and it actually flows through CentOS these days (“centpkg import” is used), so it should prevent the recurrence of the “tree” problem. Unlike other parts of the tooling, centpkg seems to know about the “+” rewriting (to “plus”), so that's not going to help us to prevent future mistakes in that area, though.
What should we do here? We have a couple of packages that are basically impossible to maintain in the present state in CentOS Stream.
One possible way forward could be:
- Rename the tree package (starting with Fedora).
- Rename all packages with + in their names (also in Fedora).
- Ban + in future source package names.
- For every REPO, the RPM spec file must be called REPO.spec, and the source RPM name must be REPO.
I'm not sure how good RPM is at source package renaming, though. If the repository name and the .spec file name and source package name differ (due to the “+” rewriting or the dump/restore thing), we end up with tooling issues again (like we had with dump/restore). If we rename the package outright, it affects the binary packages as well, and might need an exception at this point.
My worry is that people have been saying “we'll deal with these few exceptions manually”, but as far as I can tell, that is just not what's happening. RPM components that should be trivially to maintain are suddenly very difficult.
Thanks, Florian
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
We should consider renaming the tree repository in Fedora and CentOS Stream/RHEL, and leave the + packages alone. We've asked for fixes in gitlab to support the proper naming including '+' characters.
There are other source packages that don't match 1:1 with their dist-git repositories, so I'm not sure how much trouble a hard requirement would cause.
At least for pagure, it might be worth changing the slug from /tree/ to /filelist/ for 6.0 so that this isn't a problem anymore for the "tree" package...
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
We'd probably still need to change the name of the tree repo. When we asked Gitlab about allowing that slug it was a no-go from their perspective.
--Brian
On Wed, Sep 1, 2021 at 12:01 PM Brian Stinson brian@bstinson.com wrote:
On Wed, Sep 1, 2021, at 10:53, Neal Gompa wrote:
On Wed, Sep 1, 2021 at 11:44 AM Brian Stinson brian@bstinson.com wrote:
On Wed, Sep 1, 2021, at 10:32, Florian Weimer wrote:
- Josh Boyer:
Gitlab has a repository aliasing mechanism. It could be a gradual transition for existing packages.
No. This is extremely excessive. We already have namespaces, and the list of reserved names is already known. Of that list, there is a single one today that actually has an RPM that overlaps. Adding content to RHEL is not a wild west process, so we can control what our SRPMs are named as they are added going forward.
Okay, so the prefix isn't going to fly. The “+” problem is also more widespread, and the prefix does not solve that at all.
I checked the package addition process, and it actually flows through CentOS these days (“centpkg import” is used), so it should prevent the recurrence of the “tree” problem. Unlike other parts of the tooling, centpkg seems to know about the “+” rewriting (to “plus”), so that's not going to help us to prevent future mistakes in that area, though.
What should we do here? We have a couple of packages that are basically impossible to maintain in the present state in CentOS Stream.
One possible way forward could be:
- Rename the tree package (starting with Fedora).
- Rename all packages with + in their names (also in Fedora).
- Ban + in future source package names.
- For every REPO, the RPM spec file must be called REPO.spec, and the source RPM name must be REPO.
I'm not sure how good RPM is at source package renaming, though. If the repository name and the .spec file name and source package name differ (due to the “+” rewriting or the dump/restore thing), we end up with tooling issues again (like we had with dump/restore). If we rename the package outright, it affects the binary packages as well, and might need an exception at this point.
My worry is that people have been saying “we'll deal with these few exceptions manually”, but as far as I can tell, that is just not what's happening. RPM components that should be trivially to maintain are suddenly very difficult.
Thanks, Florian
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
We should consider renaming the tree repository in Fedora and CentOS Stream/RHEL, and leave the + packages alone. We've asked for fixes in gitlab to support the proper naming including '+' characters.
There are other source packages that don't match 1:1 with their dist-git repositories, so I'm not sure how much trouble a hard requirement would cause.
At least for pagure, it might be worth changing the slug from /tree/ to /filelist/ for 6.0 so that this isn't a problem anymore for the "tree" package...
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
We'd probably still need to change the name of the tree repo. When we asked Gitlab about allowing that slug it was a no-go from their perspective.
I'm not surprised. But at least it doesn't have to be a problem for Fedora anymore if I change it in pagure.
On Wednesday, September 1, 2021 5:32:06 PM CEST Florian Weimer wrote:
- Josh Boyer:
Gitlab has a repository aliasing mechanism. It could be a gradual transition for existing packages.
No. This is extremely excessive. We already have namespaces, and the list of reserved names is already known. Of that list, there is a single one today that actually has an RPM that overlaps. Adding content to RHEL is not a wild west process, so we can control what our SRPMs are named as they are added going forward.
Okay, so the prefix isn't going to fly. The “+” problem is also more widespread, and the prefix does not solve that at all.
I checked the package addition process, and it actually flows through CentOS these days (“centpkg import” is used), so it should prevent the recurrence of the “tree” problem. Unlike other parts of the tooling, centpkg seems to know about the “+” rewriting (to “plus”), so that's not going to help us to prevent future mistakes in that area, though.
What should we do here? We have a couple of packages that are basically impossible to maintain in the present state in CentOS Stream.
One possible way forward could be:
- Rename the tree package (starting with Fedora).
I have initiated the package rename request in Fedora:
https://bugzilla.redhat.com/2001467
Kamil
- Rename all packages with + in their names (also in Fedora).
- Ban + in future source package names.
- For every REPO, the RPM spec file must be called REPO.spec, and the source RPM name must be REPO.
I'm not sure how good RPM is at source package renaming, though. If the repository name and the .spec file name and source package name differ (due to the “+” rewriting or the dump/restore thing), we end up with tooling issues again (like we had with dump/restore). If we rename the package outright, it affects the binary packages as well, and might need an exception at this point.
My worry is that people have been saying “we'll deal with these few exceptions manually”, but as far as I can tell, that is just not what's happening. RPM components that should be trivially to maintain are suddenly very difficult.
Thanks, Florian
-
Brian Stinson -
Florian Weimer -
Josh Boyer -
Kamil Dudka -
Ken Dreyer -
Neal Gompa -
Patrick Riehecky