Trying to set up a clean upgrade path for celestia

[Mattia Verga]

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?

[Dan Čermák]

Hi,

On February 11, 2023 1:26:46 PM UTC, Mattia Verga <mattia.verga(a)proton.me&gt; 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/[e-mail]...
>Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Mamoru TASAKA]

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

[Mattia Verga]

>  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

[Miro Hrončok]

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: [phone]
IRC: mhroncok

[Mattia Verga]

>  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