Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=891194 --- Comment #4 from T.C. Hollingsworth <tchollingsworth@xxxxxxxxx> --- (In reply to comment #3) > > Tests aren't currently run due on most Node.js modules to the lack of the TAP > testing framework being packaged for Fedora. > > I didn't found nodejs-tap, but I thought this was because it was in bundle > of nodejs-devel. I do not want to block on it, but given the number of > packages, it is IMHO easier to do it right now, than go back later and > enable it on every packages. My primary motivation for waiting on TAP/%check is so that Koji/mock can continue to build these packages. If I were to package TAP and add the necessary BuildRequires, mock/Koji won't be able to build most packages until the necessary packages are included in the distribution. If that's fine by everyone, I'll gladly do the packaging work and add %check sections to all my specs. > > Do we really have to kill off the EL5isms just yet? > > For EL5ism, I am in the camp of those thinking that we should start to clean > now if we want to get ride of them in 2020, rather than starting to get ride > once EL5 is really dead in 2020. I wouldn't be the slightest bit surprised if some provenpackager already has a script ready to strip these project-wide as soon as they can. ;-) > I will not fight for this ( especially since packagers can perfectly add > them back later after the review ), but I would really prefer to have people > submitting packages for rawhide to be as warning free as possible on > fedora-review, based on the current rawhide. Each time spent cleaning the > report of f-r is time not spend on others packages review. And each subtlity > added is adding to the work of review, and I think we should simplify and > enforce the best practice. I appreciate this, but several members of the Node.js community have expressed strong interest in EL5 support, so I'd like to continue to make it as easy as possible to support them for the time being. (And believe me, *nobody* wants to see EL5 die more than the sysadmins still stuck supporting it. ;-) > > Pure-JavaScript Node modules are installed in /usr/lib, consistent with both > > upstream and other interpreted languages in the distribution (such as Python > and Ruby). > > Ruby place gems in /usr/share/, and python should permit to use /usr/share > for python 3.3 ( IIRC what a upstream told me a few months ago ). In fact, > we have here a conflict between "follow the FHS" and "follow upstream", but > I do not think this is the place or time to solve it, so for now, let's > follow upstream. I think however that suggesting to upstream to support the > FHS would be nice ( ie, support /usr/lib and /usr/share ). I guess once a > node-sig is created, that would be a nice starter for discussion :) I don't understand how using /usr/lib for this violates the FHS. It says "/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts" and these are clearly libraries, even though they aren't binary. I see the utility in a binary-only /usr/lib, but I also really don't see that happening, considering there's a strong movement to move non-binary default system configuration (such as systemd units) to /usr/lib, and they seem to be making more progress than those trying to move interpreted language code out of /usr/lib thus far. So, I won',t be joining the fight to move stuff to /usr/share, but I won't stand in the way either. :-) -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Z2jUBhy9nZ&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review