Skip to content
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

Drop --database and --no-database, split?/drop sqliterepo_c #377

Open
kontura opened this issue Aug 8, 2023 · 5 comments
Open

Drop --database and --no-database, split?/drop sqliterepo_c #377

kontura opened this issue Aug 8, 2023 · 5 comments
Labels
Triaged Someone on the DNF team has read the issue and determined the next steps to take

Comments

@kontura
Copy link
Contributor

kontura commented Aug 8, 2023

  • The --database and --no-database options could be dropped entirely in favor of users deliberately calling sqliterepo_c

    • EL7 is the only significant beneficiary, and EL7 will be EOL in a year
    • As per the proposal that was submitted to fedora-devel, createrepo_c would not necessarily generate EL7-compatible repos by default due to the treatment of comps metadata anyway - this would be an even less disruptive than that as yum is perfectly capable of handling repos without sqlite metadata, it is merely preferred if present.
  • sqliterepo_c could be split into a new package so that it could be dropped at some point in the future without breaking createrepo_c's semantic versioning

    • Or maybe it makes sense to just remove entirely, now, as per the above points? Splitting the package off is just a conservative option.

Pulp currently does use createrepo_c's sqlite metadata support, but we're going to drop it in the near future.

Originally posted by @dralley in #338 (comment)

@j-mracek
Copy link
Contributor

j-mracek commented Aug 8, 2023

What would be benefit of the split?

@dralley
Copy link
Contributor

dralley commented Aug 8, 2023

so that it could be dropped at some point in the future without breaking createrepo_c's semantic versioning

I think that was written before the point where you mentioned that we'd probably just do a 2.0 in a couple of years, though, and it wouldn't be a big deal.

@jan-kolarik jan-kolarik removed their assignment Aug 15, 2023
@j-mracek
Copy link
Contributor

I suggest to deliver the change with 2.0 version.

@dralley
Copy link
Contributor

dralley commented Aug 22, 2023

@j-mracek Do you want to have a deprecation warning on --database before then, or just drop it.

@j-mracek
Copy link
Contributor

Documented deprecation without warning is a good first step.

@j-mracek j-mracek added the Triaged Someone on the DNF team has read the issue and determined the next steps to take label Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Triaged Someone on the DNF team has read the issue and determined the next steps to take
Projects
None yet
Development

No branches or pull requests

4 participants