Dne 29. 07. 25 v 23:03 Fabio Valentini napsal(a):
On Tue, Jul 29, 2025 at 10:38 PM Elliott Sales de Andrade
wrote:
On Tue, Jul 29, 2025 at 4:16 PM Jos de Kloe wrote:
Hi,
as suggested on this Directory_Replacement page I tried to solve this
problem by adding a little lua scriptlet.
Unfortuna
Hi Orion,
I just built eccodes version 2.42.0-3 which should solve this issue.
I did this by reverting the upstream change, and replaced the symbolic
links with a copy of their target.
Downside of this is that the data package will increase in size, and
that I will have to maintain this patc
Hi,
I can confirm that the scriptlet still works, at least for
symlink-to-directory, I'm currently using it for a nodejs change.
I have initially struggled to make it works as it in my case I have
apparently needed to specify the package name with* -n option*, like so:
%pretrans -n %{pkgname} -p
On 7/29/25 11:03 PM, Fabio Valentini wrote:
On Tue, Jul 29, 2025 at 10:38 PM Elliott Sales de Andrade
wrote:
On Tue, Jul 29, 2025 at 4:16 PM Jos de Kloe wrote:
Hi,
as suggested on this Directory_Replacement page I tried to solve this
problem by adding a little lua scriptlet.
Unfortunately it
Hi,
thanks for this answer.
Actually it is not me, but upstream who decided to exchange some
directories by symbolic links.
So the only thing I can do I guess is to patch the package and replace
the symlinks again by the directory to which they point.
Jos
On 7/29/25 10:37 PM, Elliott Sale
On Tue, Jul 29, 2025 at 10:38 PM Elliott Sales de Andrade
wrote:
>
> On Tue, Jul 29, 2025 at 4:16 PM Jos de Kloe wrote:
> >
> > Hi,
> >
> > as suggested on this Directory_Replacement page I tried to solve this
> > problem by adding a little lua scriptlet.
> > Unfortunately it seems not to work fo
On Tue, Jul 29, 2025 at 4:16 PM Jos de Kloe wrote:
>
> Hi,
>
> as suggested on this Directory_Replacement page I tried to solve this
> problem by adding a little lua scriptlet.
> Unfortunately it seems not to work for me so I must be missing some
> details here.
You aren't missing anything. The s
Hi,
as suggested on this Directory_Replacement page I tried to solve this
problem by adding a little lua scriptlet.
Unfortunately it seems not to work for me so I must be missing some
details here.
I documented my current attempts on bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=23843
Hi Karolina,
thanks for this hint.
I 'll see if I can fix this then by adding this to the spec file.
Cheers,
Jos
On 7/29/25 1:50 PM, Karolina Surma wrote:
On 7/29/25 13:33, Jos de Kloe wrote:
As these symlinks have been generated by an earlier install of the
same package, an upgrade should be
On 7/29/25 13:33, Jos de Kloe wrote:
As these symlinks have been generated by an earlier install of the same
package, an upgrade should be able to replace them I think.
So this seems an rpm bug to me.
Is there anything I can do as eccodes packager to fix this?
Hi,
It looks like a case descr
As these symlinks have been generated by an earlier install of the same
package, an upgrade should be able to replace them I think.
So this seems an rpm bug to me.
Is there anything I can do as eccodes packager to fix this?
Jos
On 7/29/25 12:13 PM, Michael Schwendt wrote:
On Mon, 28 Jul 2025
On Mon, 28 Jul 2025 19:45:15 -0600, Orion Poplawski wrote:
> Can someone explain this to me?
>
> sudo dnf upgrade -y eccodes\*
> install of eccodes-data-2.42.0-2.fc43.noarch conflicts with file from
> package eccodes-data-2.40.0-1.fc43.noarch
>- file /usr/share/eccodes/definitions/bufr/ta
Can someone explain this to me?
sudo dnf upgrade -y eccodes\*
Updating and loading repositories:
Repositories loaded.
PackageArch
Version Repository
Size
Upgrading:
eccodes
13 matches
Mail list logo