-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make various release file fields user configurable #449
Comments
Closes #443 This is a quick and dirty workaround to prevent apt-secure from constantly requiering users to run the following: apt-get update --allow-releaseinfo-change This fix changes the pulp_deb publication behaviour. To mitigate, the old behaviour can be renabled by setting SET_RELEASE_FILE_LABEL and SET_RELEASE_FILE_VERSION to True. For a long term fix, additional new features and behaviour changes are now planned: #449
The title of this ticket remains as valid as ever, but the proposed implementation requires significant rethink! |
|
@quba42, I'd be happy to take a swing at this one (I am already looking for a starter project to contribute to this plugin), but it is not clear to me from your comment why the design needs a rethink. Is there further information available somewhere else for that? |
@mikalstill I am afraid, I don't always keep the pulp_deb GitHub issues fully up to date (it's on my todo list), because we also use an internal issue tracker in addition to this one. "The design issues" I allude to in this thread are not reflected in an issue right now (I will open one today and link it from this thread). The short version as relates to this issue, is that we no longer want to store any additional fields on the |
Note: I have now added an issue for the above mentioned "design issues": #599 |
Also create a `PRESERVE_EXTRA_RELEASE_FIELDS` setting that will set these fields during sync. Defaults to False to preserve backwards compatibility. fixes pulp#449
Also create a `PRESERVE_EXTRA_RELEASE_FIELDS` setting that will set these fields during sync. Defaults to False to preserve backwards compatibility. fixes pulp#449
Also create a `PRESERVE_EXTRA_RELEASE_FIELDS` setting that will set these fields during sync. Defaults to False to preserve backwards compatibility. fixes pulp#449
Also create a `PRESERVE_EXTRA_RELEASE_FIELDS` setting that will set these fields during sync. Defaults to False to preserve backwards compatibility. fixes pulp#449
Also set `repo_key_fields` on Release and ReleaseFile to ensure that if new Releases get created (due to the new fields that will get set), they won't duplicate old Releases in Repo Versions that got created before without version, origin, etc. fixes pulp#449
Also set `repo_key_fields` on Release and ReleaseFile to ensure that if new Releases get created (due to the new fields that will get set), they won't duplicate old Releases in Repo Versions that got created before without version, origin, etc. fixes pulp#449
I upvote this. In our scenario we would like to have all mirrored repositories in pulp made available to the system and then differ what to install with pin-priorities through apt preferences. This makes it easier to manage the systems for us but results in the possibility that we sometimes have 2 or 3 repositories with different versions active, let's take the example with mariadb: We can't use the filters for neither release/origin as it's the same and thus we would prioritize all repos at the same time. If we can set our own origin or label it would be easy to have this solved. |
[noissue] This reverts commit a0bead2. Together with issue pulp#449 this implies the Release file Label and Version fields now use values as synced from the upstream Release file if present. We plan to re-add an option to not publish these fields at all (default behaviour since at least pulp_deb 2.18.0), but there will be no way to go back to the problematic internal values used pre 2.18.0 or when the PUBLISH_RELEASE_FILE_* settings were set to True.
[noissue] This reverts commit a0bead2. Together with issue pulp#449 this implies the Release file Label and Version fields now use values as synced from the upstream Release file if present. We plan to re-add an option to not publish these fields at all (default behaviour since at least pulp_deb 2.18.0), but there will be no way to go back to the problematic internal values used pre 2.18.0 or when the PUBLISH_RELEASE_FILE_* settings were set to True.
[noissue] This reverts commit a0bead2. Together with issue pulp#449 this implies the Release file Label and Version fields now use values as synced from the upstream Release file if present. We plan to re-add an option to not publish these fields at all (default behaviour since at least pulp_deb 2.18.0), but there will be no way to go back to the problematic internal values used pre 2.18.0 or when the PUBLISH_RELEASE_FILE_* settings were set to True.
fixes pulp#449 Co-author: Quirin Pamp <pamp@atix.de>
fixes pulp#449 Co-author: Quirin Pamp <pamp@atix.de>
[noissue] This reverts commit a0bead2. Together with issue pulp#449 this implies the Release file Label and Version fields now use values as synced from the upstream Release file if present. We plan to re-add an option to not publish these fields at all (default behaviour since at least pulp_deb 2.18.0), but there will be no way to go back to the problematic internal values used pre 2.18.0 or when the PUBLISH_RELEASE_FILE_* settings were set to True.
fixes pulp#449 Co-author: Quirin Pamp <pamp@atix.de>
[noissue] This reverts commit a0bead2. Together with issue pulp#449 this implies the Release file Label and Version fields now use values as synced from the upstream Release file if present. We plan to re-add an option to not publish these fields at all (default behaviour since at least pulp_deb 2.18.0), but there will be no way to go back to the problematic internal values used pre 2.18.0 or when the PUBLISH_RELEASE_FILE_* settings were set to True.
fixes pulp#449 Co-author: Quirin Pamp <pamp@atix.de>
Is your feature request related to a problem? Please describe.
This feature is intended to provide a long term solution for #443 while also empowering users to use pulp_deb repos in combination with "APT pinning" and "unattended upgrade" workflows.
Describe the solution you'd like
If possible, consider the possibility of respecting arbitrary upstream and user supplied release file fields?
Additional context
#443 Should provide a backportable bugfix solution for the same problem, while this ticket provides a new design approach as a long term solution.
The text was updated successfully, but these errors were encountered: