| Summary: | new ebuild: www-servers/meteor - An open-source platform for building top-quality web apps in a fraction of the time. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tom Wijsman (TomWij) (RETIRED) <tomwij> |
| Component: | New packages | Assignee: | Tom Wijsman (TomWij) (RETIRED) <tomwij> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | licenses, proxy-maint, sandino |
| Priority: | Normal | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
meteor-0.5.0.ebuild
meteor-0.5.2.ebuild meteor-0.5.3.ebuild ODbL-1.0 npm npm |
||
First of all, add 'inherit vcs-snapshot' after EAPI definition and remove src_unpack() and 'cd ${P}' from src_prepare(). Also, src_prepare() looks ugly(and tries to download some stuff, which is not good). And last - src_install() tries to install files to /usr/local/* - that's COMPLETELY forbidden, according to devmanual(http://devmanual.gentoo.org/general-concepts/filesystem/index.html). This is a quick check of your ebuild, i did not test it thoroughly, just a couple of things that you MUST improve if you want this ebuild in main tree.
Hi, A couple of comments: Description is huge :) Could you explain what are all these "touch .git, rm .git" stuff in the src_prepare function ? What are you trying to do in src_unpack? Is not the default one good for you? sed needs || die cp/mkdir/ln in src_install should be replaced by insinto-doins/dodir/dosym LICENSE should be a value from the /usr/portage/licenses/ directory and not an http link I think the http://github can be replaced by mirror://github. Have a look on /usr/portage/profiles/thirdpartymirrors (IIRC). Anyway this is minor . > Also, src_prepare() looks ugly(and tries to download some stuff, which is not good). I'll see if I can replicate that download from within SRC_URI which can do platform based fetching. I'll also try to write a patch to disable updating in Meteor itself. > And last - src_install() tries to install files to /usr/local/* - that's COMPLETELY forbidden. Yeah, I don't understand why they did that and I should indeed follow that layout. Would /usr/bin/meteor be better? > Could you explain what are all these "touch .git, rm .git" stuff in the src_prepare function ? Will add descriptive comments to the ebuild. Perhaps that part can be fixed through a patch that disables the .git check instead. > This is a quick check of your ebuild, i did not test it thoroughly, just a couple of things that you MUST improve if you want this ebuild in main tree. Okay, marking this bug NEEDINFO for now. Will attempt to improve this ebuild over time and reopen this bug with a new attachment once done. Thank you for the feedback, I'll try to mitigate the issues where possible. No need to close it. The request for an ebuild for this package is still valid for anyone else who want to write one Created attachment 331302 [details] meteor-0.5.2.ebuild Previous ebuild was my first, since then I've read all the reference links from the New developer quiz so I'm now better aware about all the rules. Applied almost all your comments to the ebuild, it looks much better now! Still two things left to do from what I see: 1. There is only a mirror entry for cloud.github but not for github itself, still need to look into whether I could use the cloud somehow... 2. Some QA issues left, this is because Meteor brings its own version from node, mongodb and node modules. These need to move into RDEPEND, and require Meteor to be patched to use what is globally present on the system instead of what is inside the Meteor directory. For this reason, I'm using /opt/meteor for now. There are also upstream bugs going on to make Meteor embrace package managers: - https://github.com/meteor/meteor/issues/474 (mine, about the FHS; although it appears not explicitly using /usr/local/bin keeps Meteor working, leaving it open so they do it right for other distros too) - https://github.com/meteor/meteor/pull/516 (had two prior closed bugs, someone finally poked them with a pull requst and a direct action instead) Almost forgot to ask: How should I deal with the licenses? See the LICENSES comment. (In reply to comment #6) > Almost forgot to ask: How should I deal with the licenses? See the LICENSES > comment. Depends. You can either add the missing licenses or rename LICENSE.txt to meteor.txt and add it there see devmanual http://devmanual.gentoo.org/general-concepts/licenses/index.html also adding licenses@gentoo.org to tell us what's the preferred approach. (In reply to comment #7) > Depends. You can either add the missing licenses or rename LICENSE.txt to > meteor.txt and add it there > > see devmanual > http://devmanual.gentoo.org/general-concepts/licenses/index.html > > also adding licenses@gentoo.org to tell us what's the preferred approach. It's much preferred _not_ to add one giant license file, but to disentangle it (which has to be done in any case, in order to determine if it is Free Software). It is straight forward here: MIT Apache-2.0 BSD-2 BSD openssl public-domain WTFPL-2 Unlicense AGPL-3 Boost-1.0 ZLIB || ( BSD-2 GPL-2+ ) HPND npm ODbL-1.0 CCPL-Attribution-ShareAlike-2.0 We have almost all of them, except for npm and ODBl-1.0. The "npm" license was discussed by Debian folks here and found to be free: <http://lists.debian.org/debian-legal/2012/01/msg00104.html> The text of ODbL-1.0 is here: <http://www.opendatacommons.org/wp-content/uploads/2009/06/odbl-10.txt> It is approved by the FSF (it would go to the @FSF-APPROVED-OTHER license group), but not by the OSI. (In reply to comment #8) > (In reply to comment #7) > > Depends. You can either add the missing licenses or rename LICENSE.txt to > > meteor.txt and add it there > > > > see devmanual > > http://devmanual.gentoo.org/general-concepts/licenses/index.html > > > > also adding licenses@gentoo.org to tell us what's the preferred approach. > > It's much preferred _not_ to add one giant license file, but to disentangle > it (which has to be done in any case, in order to determine if it is Free > Software). It is straight forward here: > > MIT Apache-2.0 BSD-2 BSD openssl public-domain WTFPL-2 Unlicense > AGPL-3 Boost-1.0 ZLIB || ( BSD-2 GPL-2+ ) HPND npm ODbL-1.0 > CCPL-Attribution-ShareAlike-2.0 > > We have almost all of them, except for npm and ODBl-1.0. > > The "npm" license was discussed by Debian folks here and found to be free: > <http://lists.debian.org/debian-legal/2012/01/msg00104.html> > > The text of ODbL-1.0 is here: > <http://www.opendatacommons.org/wp-content/uploads/2009/06/odbl-10.txt> > It is approved by the FSF (it would go to the @FSF-APPROVED-OTHER license > group), but not by the OSI. Thank you very much Ulrich. > which has to be done in any case, in order to determine if it is Free Software Learned something very important here, thanks. > It is approved by the FSF (it would go to the @FSF-APPROVED-OTHER license group), but not by the OSI. Does "no approvement by the OSI" have any implications regarding inclusion of the ebuild in the portage tree? Or does approvement by FSF alone suffice? (In reply to comment #10) > > It is approved by the FSF (it would go to the @FSF-APPROVED-OTHER license > > group), but not by the OSI. > > Does "no approvement by the OSI" have any implications regarding inclusion > of the ebuild in the portage tree? Or does approvement by FSF alone suffice? It doesn't have any implications for inclusion in the tree. However, it affects to what license groups (see profiles/license_groups) the license can be added. Here, both ODbL-1.0 and npm will still end up in the @FREE group, via @FSF-APPROVED-OTHER and @MISC-FREE, respectively. (In reply to comment #10) > > which has to be done in any case, in order to determine if it is Free Software > > Learned something very important here, thanks. > > > It is approved by the FSF (it would go to the @FSF-APPROVED-OTHER license group), but not by the OSI. > > Does "no approvement by the OSI" have any implications regarding inclusion > of the ebuild in the portage tree? Or does approvement by FSF alone suffice? So please add all the licences in the ebuild's LICENSE variable, and attach those we don't have in the tree Created attachment 335116 [details]
meteor-0.5.3.ebuild
Version bump, added licenses and sorted them.
Created attachment 335118 [details] ODbL-1.0 License from http://www.opendatacommons.org/wp-content/uploads/2009/06/odbl-10.txt referenced to from LICENSE.txt. Created attachment 335120 [details]
npm
npm license copied verbatim from LICENSE.txt.
(In reply to comment #15) > Created attachment 335120 [details] > npm > > npm license copied verbatim from LICENSE.txt. This should be cut off after the paragraph in all-caps. The text following it are just notes that are not part of the license itself. Created attachment 335168 [details]
npm
I see now, thanks.
+*meteor-0.5.4 (07 Feb 2013) + + 07 Feb 2013; Tom Wijsman <TomWij@gentoo.org> +metadata.xml, + +meteor-0.5.4.ebuild: + New ebuild for meteor. Thanks to the reviewers. See bug #442210. |
Created attachment 328708 [details] meteor-0.5.0.ebuild Meteor is an open-source platform for building top-quality web apps in a fraction of the time, whether you're an expert developer or just getting started. The ebuild has been in my overlay (TomWij) for a while and I think it can move into Portage. Marked as unstable at the moment so we can see how it goes and request stabilization over time. I'm up for becoming a proxy maintainer for this package if that's possible. Since this is my first ebuild, feedback is welcome...