Skip to content

Conversation

@NicholasBHubbard
Copy link
Contributor

@NicholasBHubbard NicholasBHubbard commented Aug 30, 2023

description of this PR provided here: #1972 (comment)

@NicholasBHubbard
Copy link
Contributor Author

NicholasBHubbard commented Aug 30, 2023

not surprised that CI tests fail considering I broke all but the cpan and gem input types.

@NicholasBHubbard NicholasBHubbard changed the title separate installation logic out of input methods for gem and cpan Extract the build/installation steps out of the input method for future source-based package support Aug 30, 2023
@jordansissel
Copy link
Owner

I’m away from my workstation at the moment and will try to get this evaluated when I can in a week or two :)

@jordansissel
Copy link
Owner

This looks like a great start :)

I have some ideas and I'll shoot you a PR for them soon -- notably, changing the shell code from a multiline string to be an array of commands. I"ll also see about moving this a bit forward towards getting the test suite to pass again.

@NicholasBHubbard
Copy link
Contributor Author

I look forward to it!

@NicholasBHubbard
Copy link
Contributor Author

Hey @jordansissel, wondering if you ever got a chance to look at this more in depth. Best regards.

@jordansissel
Copy link
Owner

I've been thinking about this PR for a bit and have some additional thoughts -

Comparing the shell_code with build_and_install, it handles things slightly differently and runs different (though similar) commands. In practice, this may be necessary, but It would probably be necessary to handle fpm flags the same (use the same perl path, etc?)

  • An example for flags, the perl path attributes[:cpan_perl_bin] is not used here, but maybe should?
  • The cleanup done in build_and_install is not performed in shell_code.

It's also unclear how we would go from these build/install strings to something that Debian or rpmbuild can use successfully. For example, with rpmbuild, instead of make install, you'd want to use make install DESTDIR=%{buildroot}. Debian and other packages ecosystems provide DESTDIR or other settings in different ways.

If I look at Archive::Zip for Fedora, Debian, and Arch Linux, we can start to see how each platform varies even for a simple perl module:

Notably: FreeBSD ports has a very tiny entry for Archive::Zip because bsd.port.mk already knows how to handle perl modules. Debian also has some builtin knowledge here as evidenced by a basically-empty rules file.

Is the installation directory (aka DESTDIR, %buildroot, etc) the only part missing? Or are we missing more? Templating this would be ok, I think, so instead of:

-      install_procedure = "./Build install\n"
+      install_procedure = "./Build install --destdir {DESTDIR}\n"

And for srpm, {DESTDIR} would become %buildroot; for Debian, it would become $(DESTDIR) if invoked from a debian rules (make) file; for Arch/pacman, it would be ${pkgdir}

Are we missing anything other parameters/templating necessary in these build/install steps? For example, do we need to compute a list of files here? or no? (for example, rpm's %files list, etc).

(Out of scope for this PR: architecture settings like noarch/all/etc, dependencies, build dependencies, etc)

@wbraswell
Copy link
Contributor

@jordansissel
Wow thanks for all the great ideas and feedback! We will review and get back to you soon. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants