getsolus / eopkg

eopkg - Solus package manager implemented in python3
8 stars 9 forks source link

The problem of installing the package after the build. A cyclic call #26

Open AlexanderZhirov opened 11 months ago

AlexanderZhirov commented 11 months ago

Summary

I'm trying to assemble a package. There are no obvious problems with the assembly. I get two packages at the output. Trying to install - I get a batch manager error.

name       : freetds
version    : 1.4.6
release    : 1
source     :
    - https://www.freetds.org/files/stable/freetds-1.4.6.tar.bz2 : 813802a1c6bc02fe1696b6ea31aa535225719777736b5bfc23a3a17858956ac0
homepage   : https://www.freetds.org
license    :
    - GPL-2.0-or-later
    - LGPL-2.0-or-later
component  : database
summary    : Tabular Datastream Library
description: |
    Library for accessing Sybase and MS SQL Server databases
builddeps  :
    - unixodbc-devel
    - pam-krb5
    - pkgconfig(readline)
    - pkgconfig(openssl)
setup      : |
    ./configure --prefix=/usr \
                --sysconfdir=/etc/freetds \
                --enable-msdblib \
                --enable-krb5 \
                --with-unixodbc=/usr \
                --with-openssl \
                --enable-odbc
build      : |
    %make
install    : |
    %make_install

Steps to reproduce

  1. Build the package
  2. Try to install it

Expected result

Installing the packages

Actual result

# eopkg it freetds-1.4.6-1-1-x86_64.eopkg freetds-devel-1.4.6-1-1-x86_64.eopkg 
Updates available, checking reverse dependencies of runtime dependencies for safety.
Unhandled internal exception.
Please file a bug report to <https://github.com/getsolus/package-management/>.
<class 'pisi.graph.CycleException'>: Encountered cycle ['freetds-devel', 'freetds']
Please use 'eopkg help' for general help.

Traceback:
  File "/usr/bin/eopkg", line 78, in <module>
    cli.run_command()
  File "/usr/lib/python2.7/site-packages/pisi/cli/pisicli.py", line 138, in run_command
    self.command.run()
  File "/usr/lib/python2.7/site-packages/pisi/cli/install.py", line 109, in run
    pisi.api.install(packages, ctx.get_option('reinstall') or reinstall)
  File "/usr/lib/python2.7/site-packages/pisi/api.py", line 65, in wrapper
    ret = func(*__args,**__kw)
  File "/usr/lib/python2.7/site-packages/pisi/api.py", line 447, in install
    return pisi.operations.install.install_pkg_files(packages, reinstall)
  File "/usr/lib/python2.7/site-packages/pisi/operations/install.py", line 245, in install_pkg_files
    order = G_f.topological_sort()
  File "/usr/lib/python2.7/site-packages/pisi/graph.py", line 133, in topological_sort
    self.dfs(lambda u: list.append(u))
  File "/usr/lib/python2.7/site-packages/pisi/graph.py", line 101, in dfs
    self.dfs_visit(u, finish_hook)
  File "/usr/lib/python2.7/site-packages/pisi/graph.py", line 109, in dfs_visit
    self.dfs_visit(v, finish_hook)
  File "/usr/lib/python2.7/site-packages/pisi/graph.py", line 118, in dfs_visit
    raise CycleException(cycle)

Environment

Repo

Shannon (stable)

Desktop Environment

Budgie

System details

OS: Solus x86_64 Kernel: 6.5.11-263.current

Other comments

No response

ReillyBrogan commented 11 months ago

So this usually happens when the main package has a dependency on the devel package and vice versa. The solution is to make it so that the main package does not depend on the devel package, or just merge the devel package into the main package (for packages which don't need a development package).

It should be possible to figure out why ypkg is adding a dependency on -devel onto main if you share the build log as well as the pspec file.

ReillyBrogan commented 11 months ago

Also, this isn't really a bug in eopkg/ypkg but an issue with the construction/patterning of the packages itself.

AlexanderZhirov commented 11 months ago

For some reason, the links to *.so in the develop packages break

pspec.tar.gz

joebonrichie commented 11 months ago

try libsplit : no in the package.yml

ReillyBrogan commented 11 months ago

Based on that pspec the most likely cause is that the package is creating the sonames incorrectly. It should be that (for example) libsybdb.so.5.1.0 is the lib that has actual data, libsybdb.so.5 is a symlink to that, andlibsybdb.sois a symlink to that. If that ordering is messed up somehow (for example thelibsybdb.so` is the file with actual data and not a symlink, and the other things link to that) then it could cause the automatic dependencies to get confused as they will detect that something in the main package is a symlink to something in the devel package and create that dependency accordingly.

I'd recommend adding tree as a temporary build dep, and running tree $installdir && ls -ahl $installdir/usr/lib at the end of your install phase. Then attach the build log here and that will give us enough information to figure this out.

AlexanderZhirov commented 11 months ago

Okay, I'll do it soon and post the result here.

AlexanderZhirov commented 11 months ago

Still, yes, the links break. The screenshot shows a local assembly, when installed in the directory, all links are in place.

As a way out - create links with hands. Well, as far as it will be true.

изображение log.txt

ReillyBrogan commented 11 months ago

That is very odd, the symbolic links are indeed very much not present in the build environment. This is definitely an issue with the package build itself. Since this works when you build it manually the issue is highly likely to be one of the following two things:

Also, just double checking here, but you are running the builds with go-task build, either in a checked out version of the monorepo or in another folder that you copied the taskfile to? Or manually by running sudo solbuild build package.yml?

AlexanderZhirov commented 11 months ago
  • Some CFLAG/CXXFLAG/LDFLAG/etc that's set in the build. This would be why it's fine when you build it locally, you're probably not setting those environmental variables to match what's in the ypkg build. Check your build log to see what they're being set to and do the same exports before you build it locally. You can set one variable at a time, build it, and check if the issue is present. If it is then you know which variable has the bad argument. Once you know that you can bisect your way through the arguments of that variable until you find out exactly what argument is at fault (so test the first half of the arguments alone to see if they trigger the failure, if not then test the other half, then keep doing that until you get to one argument).

I don't quite understand what needs to be done. Can I try to build with my hands inside solbuild? What is the password from root?

AlexanderZhirov commented 11 months ago

The easiest way to solve the problem. As for the flags, I still don't understand what to do.

name       : freetds
version    : 1.4.6
release    : 1
source     :
    - https://www.freetds.org/files/stable/freetds-1.4.6.tar.bz2 : 813802a1c6bc02fe1696b6ea31aa535225719777736b5bfc23a3a17858956ac0
homepage   : https://www.freetds.org
license    :
    - GPL-2.0-or-later
    - LGPL-2.0-or-later
component  : database
summary    : Tabular Datastream Library
description: |
    Library for accessing Sybase and MS SQL Server databases
builddeps  :
    - unixodbc-devel
    - pam-krb5
    - pkgconfig(readline)
    - pkgconfig(openssl)
    - tree
setup      : |
    ./configure --prefix=/usr \
                --sysconfdir=/etc/freetds \
                --enable-msdblib \
                --enable-krb5 \
                --with-unixodbc=/usr \
                --with-openssl \
                --enable-odbc \
                --disable-static \
                --disable-docs
build      : |
    %make
install    : |
    %make_install
    rm -rf $installdir/usr/share
    ln -sf libct.so.4.0.0 $installdir/usr/lib/libct.so.4
    ln -sf libct.so.4 $installdir/usr/lib/libct.so
    ln -sf libsybdb.so.5.1.0 $installdir/usr/lib/libsybdb.so.5
    ln -sf libsybdb.so.5 $installdir/usr/lib/libsybdb.so
    ln -sf libtdsodbc.so.0.0.0 $installdir/usr/lib/libtdsodbc.so.0
    ln -sf libtdsodbc.so.0 $installdir/usr/lib/libtdsodbc.so