7:26 a.m.
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?
7:45 a.m.
Hi,
On February 11, 2023 1:26:46 PM UTC, Mattia Verga <mattia.verga(a)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(a)lists.fedoraproject.org
>To unsubscribe send an email to packaging-leave(a)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.fedoraproje...
>Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
7:54 a.m.
New subject: Trying to set up a clean upgrade path for celestia
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_Repla...
Regards,
Mamoru
10:58 a.m.
New subject: Trying to set up a clean upgrade path for celestia
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
8:56 a.m.
New subject: Trying to set up a clean upgrade path for celestia
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-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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
11:20 a.m.
New subject: Trying to set up a clean upgrade path for celestia
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
434
days inactive
438
days old
packaging@lists.fedoraproject.org
5 comments
4 participants
participants (4)
-
Dan Čermák -
Mamoru TASAKA -
Mattia Verga -
Miro Hrončok