Bug 1748233

Summary: Review Request: pgloader - Data loading tool for PostgreSQL
Product: [Fedora] Fedora Reporter: Lukas Javorsky <ljavorsk>
Component: Package ReviewAssignee: Miroslav Suchý <msuchy>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 30CC: mschorm, msuchy, package-review
Target Milestone: ---Flags: msuchy: fedora-review?
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-22 11:40:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 177841    

Description Lukas Javorsky 2019-09-03 08:07:58 UTC
Spec URL: https://github.com/ljavorsk/pgloader/blob/master/pgloader.spec
SRPM URL: https://github.com/ljavorsk/pgloader/blob/master/pgloader-3.6.1-1.fc30.src.rpm
Description: 
Data loading tool that allows to implement continuous migration              from current database to PostreSQL.                                                                                                                           It uses the COPY PostreSQL protocol to stream the data into the server.                                                                                           Pgloader can read data from CSV and DBF files, or SQLite, MySQL,                
MS SQL Server, PostgreSQL, Redshift databases.
Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=37437306
Fedora Account System Username: ljavorsk

Comment 1 Lukas Javorsky 2019-09-03 08:19:43 UTC
Description fixed:
Data loading tool that allows to implement continuous migration from current database to PostgreSQL.
It uses the COPY PostreSQL protocol to stream the data into the server.
Pgloader can read data from CSV and DBF files, or SQLite, MySQL, MS SQL Server, PostgreSQL, Redshift databases.

Comment 2 Miroslav Suchý 2019-09-03 12:11:34 UTC
I will do this one.

Comment 3 Miroslav Suchý 2019-09-03 13:43:44 UTC
Please always provide links to the raw version of files.

- If your application is a C or C++ application you must list a
  BuildRequires against gcc, gcc-c++ or clang.                                                                                                    
  Note: No gcc, gcc-c++ or clang found in BuildRequires
  See: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/

Please address these - we discussed that in person:
pgloader.x86_64: E: devel-dependency openssl-devel
pgloader.x86_64: E: wrong-script-interpreter /usr/share/doc/pgloader/docs/conf.py /usr/bin/env python3
pgloader.x86_64: W: no-manual-page-for-binary pgloader


Hmm, I am really woried about those bundles in tarball - all those pgloader-bundle-3.6.1/software/* Instead of that you have to use normal libraries and packages in Fedora. And if they do not exists there yet, they need to be packaged separately.

Comment 4 Lukas Javorsky 2019-09-03 14:34:56 UTC
Updated URLS:
Spec URL: https://raw.githubusercontent.com/ljavorsk/pgloader/master/pgloader.spec
SRPM URL: https://github.com/ljavorsk/pgloader/raw/master/pgloader-3.6.1-1.fc30.src.rpm

pgloader.x86_64: E: devel-dependency openssl-devel
- this dependency is needed as we spoke about it becasue of /usr/lib64/libcrypto.so

pgloader.x86_64: E: wrong-script-interpreter /usr/share/doc/pgloader/docs/conf.py /usr/bin/env python3
- fixed, don't include the docs/ directory at all

pgloader.x86_64: W: no-manual-page-for-binary pgloader
- python-sphinx generated man pages from docs/ directory


So it means, that it can't use it like this, and require every package there, or package them if needed?

Comment 5 Michal Schorm 2019-09-04 07:35:40 UTC
(In reply to Miroslav Suchý from comment #3)
> 
> Hmm, I am really woried about those bundles in tarball - all those
> pgloader-bundle-3.6.1/software/* Instead of that you have to use normal
> libraries and packages in Fedora. And if they do not exists there yet, they
> need to be packaged separately.

In theory yes - all of the requirements should be also separately packed, prior to this package.
However I see two main obstructions here.
1) The program is written in such a way, the Common LISP download the libraries at runtime (really, by curl).
   * The libraries are mostly latest push in the master branch of the project.
    * To resolve this and make things safer (different library version each run), we need to get them prior the runtime - either pack them, or bundle them.
     * The upstream release the bundle with specific library versions and marks this as a recommended way to pack the application to various OS.
2) There are ~70 LISP libraries in that bundle.
   Between following stable versions (of pgloader), most of them are updated to another specific version, so it would be hard to manage them packed separately.
   Given that that specific set of versions of those libraries is supported and tested configuration by the upstream, I'd stick to it for now.

Do you agree?

Comment 6 Miroslav Suchý 2019-09-10 13:06:13 UTC
In that case, it needs to follow https://fedoraproject.org/wiki/Bundled_Libraries#Requirement_if_you_bundle

Comment 7 Dominik 'Rathann' Mierzejewski 2019-09-20 09:06:06 UTC
Can you talk to upstream about not bundling or at least supporting building against shared versions of the libraries?

Comment 8 Lukas Javorsky 2020-04-22 11:30:15 UTC
Sorry for late update.

Upstream won't change the bundled libraries, so after a talk with msuchy, we've agreed on not to package this one.
It would be really difficult to watch every bundle, after every upstream's update.

This BZ can be closed now.