Dne 07. 01. 20 v 14:19 Tom Hughes napsal(a): > On 07/01/2020 13:06, Fabio Valentini wrote: > >> - ruby is weird, packaging gems is a bit of a chore, upstream has many >> knobs to fiddle with to make distro packaging hard (for example, not >> including test sources in .gem files seems to be a common practice), >> there's no canonical way of running test suites, and I think the >> %check section of all my rubygem packages is different and >> specifically tailored to the package ... > > Yeah npm does many of those things as well... > > Test files often excluded from npmjs.com tar ball and only available > on github where people often forget to tag releases. > > While "npm test" is the normal way Just FTR, there used to be "gem test" command, which was removed, because it was found unusable. Mainly because the tests are typically designed to be executed from the source repository and have many different dependencies. Since there is no "gem test" command anymore, the test suites are more commonly omitted nowadays. Vít > I'm not sure it's safe to actually > run npm during the build - we certainly don't normally. In any case > that often runs all sorts of other stuff like linters or coverage > tests that aren't relevant and require extra dependencies so we > usually look at what "npm test" actually does and run that. > > Test dependencies is another issue - the devDependencies key in the > metadata often includes lots of things that aren't needed by the tests > but are needed for other reasons by people working on the package. > > Also the npmjs.com tar ball may not even have the real source if the > package is transpiled from typescript or a different js variant. Though > in that case it's often a road block at the moment as we typically won't > have the toolchain necessary to do those build steps packaged. > > Lots of npm packages that claim to be BSD or MIT are missing the license > text is another good one. > > Decoding whether a "bin" target declared in the metadata is actually > worth exporting in /usr/bin and if so by what name is another thorny > issue to automate. > > Then of course there's the whole issue of massive dependency trees > and version mismatches unless you start packaging multiple versions > of the same libraries. > > Tom > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
