I'm trying to set up a clean upgrade path for celestia. Previously there was a monolithic 'celestia' package with everything inside it, now there will be a separate 'celestia-data' package (from a different source repository), while the former 'celestia' package will be splitted in 'celestia-common', 'celestia-gtk' and 'celestia-qt'.
The plan is that when a user upgrade from pre 1.7, it should end up with 'celestia-gtk' as default interface, which requires both 'celestia-common' and 'celestia-data'.
I have set the 'celestia' specfile as follows: %package common Obsoletes: %{name} < 1.6.3
%package gtk Requires: %{name}-common%{?_isa} = %{version}-%{release} Provides: %{name} = %{version}-%{release}
I have prepared a build at https://copr.fedorainfracloud.org/coprs/mattia/Astronomy/build/5517618/
When running an upgrade coming from pre 1.7, I get: # dnf upgrade celestia --refresh ... ========================================================================================== Package Arch Version Repository Size ========================================================================================== Installing: celestia-common x86_64 1.7.0~202302239c1c4e4-0.3.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 2.0 M sostituisce celestia.x86_64 1.6.2-0.8.beta3.fc37 Installazione dipendenze: celestia-data noarch 1.7.0~20230223ffc806d-1.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 281 M celestia-gtk x86_64 1.7.0~202302239c1c4e4-0.3.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 76 k ... Errore: Errore test di transazione: il file /usr/share/celestia/fonts dell'installazione di celestia-common-1.7.0~202302239c1c4e4-0.3.fc37.x86_64 entra in conflitto con il file del pacchetto celestia-1.6.2-0.8.beta3.fc37.x86_64
So, dnf correctly finds that celestia-common obsoletes celestia, still it complains about conflicting files.... ? Have I set up something wrong?
Hi,
On February 11, 2023 1:26:46 PM UTC, Mattia Verga mattia.verga@proton.me wrote:
I'm trying to set up a clean upgrade path for celestia. Previously there was a monolithic 'celestia' package with everything inside it, now there will be a separate 'celestia-data' package (from a different source repository), while the former 'celestia' package will be splitted in 'celestia-common', 'celestia-gtk' and 'celestia-qt'.
The plan is that when a user upgrade from pre 1.7, it should end up with 'celestia-gtk' as default interface, which requires both 'celestia-common' and 'celestia-data'.
I have set the 'celestia' specfile as follows: %package common Obsoletes: %{name} < 1.6.3
%package gtk Requires: %{name}-common%{?_isa} = %{version}-%{release} Provides: %{name} = %{version}-%{release}
I'd suggest to try to add the Provides: to both packages (and maybe the obsoletes as well), maybe that will be enough so that dnf will erase the old package first.
I have prepared a build at https://copr.fedorainfracloud.org/coprs/mattia/Astronomy/build/5517618/
When running an upgrade coming from pre 1.7, I get: # dnf upgrade celestia --refresh ... ========================================================================================== Package Arch Version Repository Size ========================================================================================== Installing: celestia-common x86_64 1.7.0~202302239c1c4e4-0.3.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 2.0 M sostituisce celestia.x86_64 1.6.2-0.8.beta3.fc37 Installazione dipendenze: celestia-data noarch 1.7.0~20230223ffc806d-1.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 281 M celestia-gtk x86_64 1.7.0~202302239c1c4e4-0.3.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 76 k ... Errore: Errore test di transazione: il file /usr/share/celestia/fonts dell'installazione di celestia-common-1.7.0~202302239c1c4e4-0.3.fc37.x86_64 entra in conflitto con il file del pacchetto celestia-1.6.2-0.8.beta3.fc37.x86_64
So, dnf correctly finds that celestia-common obsoletes celestia, still it complains about conflicting files.... ? Have I set up something wrong? _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Mattia Verga wrote on 2023/02/11 22:26:
I'm trying to set up a clean upgrade path for celestia. Previously there was a monolithic 'celestia' package with everything inside it, now there will be a separate 'celestia-data' package (from a different source repository), while the former 'celestia' package will be splitted in 'celestia-common', 'celestia-gtk' and 'celestia-qt'.
The plan is that when a user upgrade from pre 1.7, it should end up with 'celestia-gtk' as default interface, which requires both 'celestia-common' and 'celestia-data'.
I have set the 'celestia' specfile as follows: %package common Obsoletes: %{name} < 1.6.3
%package gtk Requires: %{name}-common%{?_isa} = %{version}-%{release} Provides: %{name} = %{version}-%{release}
I have prepared a build at https://copr.fedorainfracloud.org/coprs/mattia/Astronomy/build/5517618/
When running an upgrade coming from pre 1.7, I get: # dnf upgrade celestia --refresh ... ========================================================================================== Package Arch Version Repository Size ========================================================================================== Installing: celestia-common x86_64 1.7.0~202302239c1c4e4-0.3.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 2.0 M sostituisce celestia.x86_64 1.6.2-0.8.beta3.fc37 Installazione dipendenze: celestia-data noarch 1.7.0~20230223ffc806d-1.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 281 M celestia-gtk x86_64 1.7.0~202302239c1c4e4-0.3.fc37 copr:copr.fedorainfracloud.org:mattia:Astronomy 76 k ... Errore: Errore test di transazione: il file /usr/share/celestia/fonts dell'installazione di celestia-common-1.7.0~202302239c1c4e4-0.3.fc37.x86_64 entra in conflitto con il file del pacchetto celestia-1.6.2-0.8.beta3.fc37.x86_64
So, dnf correctly finds that celestia-common obsoletes celestia, still it complains about conflicting files.... ? Have I set up something wrong?
Directory -> symlink change conflict: https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacem...
Regards, Mamoru
Mattia Verga wrote on 2023/02/11 22:26:
Directory -> symlink change conflict: https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Repla...
Regards, Mamoru
Thanks, that worked! (with some ugly warnings about file not found during cleanup, but...)
Just a note about the example lua script in FPL: I think it could be a better example to define `path = rpm.expand("/path/to/dir")` rather than `path = "/path/to/dir"` so to not hardcode system dirs. I had to dig a bit into lua to find how to do that.
Thanks Mattia
On 11. 02. 23 17:58, Mattia Verga wrote:
Mattia Verga wrote on 2023/02/11 22:26:
Directory -> symlink change conflict: https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Repla...
Regards, Mamoru
Thanks, that worked! (with some ugly warnings about file not found during cleanup, but...)
Just a note about the example lua script in FPL: I think it could be a better example to define `path = rpm.expand("/path/to/dir")` rather than `path = "/path/to/dir"` so to not hardcode system dirs. I had to dig a bit into lua to find how to do that.
Sctriptlets are expanded on build time, so rpm.expand() is unnecessary and dangerous.
Don't use it in sctriptlets. Use the macros directly.
See:
https://src.fedoraproject.org/rpms/python-notebook/blob/f35/f/python-noteboo...
%pretrans -n python3-%{pypi_name} -p <lua> path = "%{python3_sitelib}/%{pypi_name}/static/components/moment" st = posix.stat(path) if st and st.type == "link" then os.remove(path) end
$ rpm -qp --scripts python3-notebook-6.4.0-4.fc35.noarch.rpm pretrans scriptlet (using <lua>): path = "/usr/lib/python3.10/site-packages/notebook/static/components/moment" st = posix.stat(path) if st and st.type == "link" then os.remove(path) end
If the rpm.expand() call actually was there, you would end up with:
path = rpm.expand("/usr/lib/python3.10/site-packages/notebook/static/components/moment")
Which is not necessary. And even if you escaped the %-signs like this:
path = rpm.expand("%%{python3_sitelib}/%{pypi_name}/static/components/moment")
You would (probably) end up with:
path = rpm.expand("%{python3_sitelib}/%{pypi_name}/static/components/moment")
Which would fail on runtime if python3-rpm-macros is not instilled.
On 11. 02. 23 17:58, Mattia Verga wrote:
Sctriptlets are expanded on build time, so rpm.expand() is unnecessary and dangerous.
Don't use it in sctriptlets. Use the macros directly.
See:
https://src.fedoraproject.org/rpms/python-notebook/blob/f35/f/python-note...
%pretrans -n python3-%{pypi_name} -p <lua> path = "%{python3_sitelib}/%{pypi_name}/static/components/moment" st = posix.stat(path) if st and st.type == "link" then os.remove(path) end
$ rpm -qp --scripts python3-notebook-6.4.0-4.fc35.noarch.rpm pretrans scriptlet (using <lua>): path = "/usr/lib/python3.10/site-packages/notebook/static/components/moment" st = posix.stat(path) if st and st.type == "link" then os.remove(path) end
If the rpm.expand() call actually was there, you would end up with:
path = rpm.expand("/usr/lib/python3.10/site-packages/notebook/static/components/moment")
Which is not necessary. And even if you escaped the %-signs like this:
path = rpm.expand("%%{python3_sitelib}/%{pypi_name}/static/components/moment")
You would (probably) end up with:
path = rpm.expand("%{python3_sitelib}/%{pypi_name}/static/components/moment")
Which would fail on runtime if python3-rpm-macros is not instilled.
Oh thanks for the tip. I was unsure if macros would have been translated when used between quotes in a lua script.
Mattia
packaging@lists.fedoraproject.org
-
Dan Čermák -
Mamoru TASAKA -
Mattia Verga -
Miro Hrončok