On Sun, Aug 05, 2018 at 11:01:56AM -0400, Nico Kadel-Garcia wrote:
> On Sun, Aug 5, 2018 at 6:01 AM, Greg Sheremeta <greg@xxxxxxxxxxxxxxxxx> wrote:
> >
> >
> > On Sun, Aug 5, 2018, 5:35 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
> >>
> >> On Sun, Aug 5, 2018, 00:43 Greg Sheremeta <greg@xxxxxxxxxxxxxxxxx> wrote:
> >>>
> >>>
> >>>
> >>> On Sat, Aug 4, 2018, 3:25 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> >>> Indeed, the build would use npm or yarn to get the JS. (the app author
> >>> writes this into the build. Not something a packager would do.)
> >>
> >>
> >> The problem with that approach is that there is no (and there cannot be
> >> cannot be) internet access during package builds.
> >
> >
> > For offline rpm builds, what I've seen on other teams is people are taking
> > the entire node_modules dir (containing all the JavaScript libraries that
> > were downloaded by yarn or npm), zipping it, and using it as a Source. We
> > are going to use that approach for my team's projects too.
> >
> > FWIW, I think the offline builds requirement is also something that should
> > be reconsidered, but that's outside the scope of this conversation.
>
> I am not currently a Fedora packager. I've had to do just this with
> commercial binaries to get it them into compatibility RPM packaging,
> so I know it's feasible. I even used to do it with Sun Java
> installation tarballs, to get sane RPM's. But if I saw you doing it in
> a project I worked on, I would try to insist on source tarballs, not
> binary tarballs. If you can't build the binary components and package
> them, I wouldn't want them bundled by some third party in a
> not-really-source tarball in some third-party environment that I know
> nothing about. It's not safe, and it goes directly against the *whole
> point* of the GPL and the concept of "free as in speech" software.
> It's pretty uncooperative with open source licenses, too, because
> almost inevitably there is going to end up being "secret sauce" in the
> build process that doesn't get published to developers or downstream
> maintainers.
There is also another problem with fetching the needed libraries and
their dependencies from the network during the build: to quote Forrest
Gump, "you never know what you're going to get". The main reason
I take part in packaging CPAN modules for Debian and I took part in
packaging them for FreeBSD before that is that this is the only way
to avoid unknown, unverified, and either buggy or malicious or both
code slipping onto the user's system.
Apologies if it feels like I'm pointing out the obvious, but it feels
like it needs to be said.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@xxxxxxxxxxxx
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx/message/V55X4X3DH6DHUYTH2HNGWUZ6FU7X4QQ2/
