Spec URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/SOURCES/fedora-dockerfiles.spec SRPM URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/SRPMS/fedora-dockerfiles-0-0.1.git202887b.fc21.src.rpm Description: This package provides a community contributed set of examples that can assist in learning about Docker containers. Use these examples to stand up test environments using the Docker container engine. Fedora Account System Username: lsm5 koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=6405939 $ rpmlint SOURCES/fedora-dockerfiles.spec SRPMS/fedora-dockerfiles-0-0.1.git202887b.fc21.src.rpm RPMS/noarch/fedora-dockerfiles-0-0.1.git202887b.fc21.noarch.rpm SOURCES/fedora-dockerfiles.spec:19: W: setup-not-quiet fedora-dockerfiles.src:19: W: setup-not-quiet 2 packages and 1 specfiles checked; 0 errors, 2 warnings.
Is it better to name it docker-fedora? Like cmake-fedora? Thanks.
(In reply to Christopher Meng from comment #1) > Is it better to name it docker-fedora? Like cmake-fedora? > > Thanks. Upstream said they aren't ready to endorse this package officially (yet). imho, something like docker-* might give the impression of official affiliation, (what do you think?) I'm told it's ok to name something fedora-PACKAGE. There seem to be quite a few of those which aren't official fedora packages. Personally I'm ok with whatever (upto majority vote).
(In reply to Lokesh Mandvekar from comment #2) > (In reply to Christopher Meng from comment #1) > > Is it better to name it docker-fedora? Like cmake-fedora? > > > > Thanks. > > Upstream said they aren't ready to endorse this package officially (yet). > imho, something like docker-* might give the impression of official > affiliation, (what do you think?) By upstream here, I mean docker and not Scott Collier (the current upstream for this package) :)
Finally getting around to the review -- sorry. /usr/share/fedora-dockerfiles needs to be owned by the package (list %dir %dir %{_datadir}/%{name} in the %files) Not necessary, but it might be cleaner to do the install part in a loop. Also: the auto-picked up deps on /bin/bash and /bin/sh are spurious, since those scripts are executed inside the container. I think that making the scripts not executable will fix that (although I'm not sure that the RUN command will still work?). So maybe filter out the deps with RPM kludges -- or else make whatever Dockerfile modifications are needed so the scripts can be shipped nonexecutable. (That actually makes most sense to me because they could theoretically actually be disastrous if run on the host accidentally.) Question for Scott: do we want to do GPLv2 or a more permissive license? Although it's some amount of overhead, it might be nice to clarify the license specifically in each Dockerfile (or at least each subdirectory); this gives us some room to use different possibly-conflicting licenses for different contributions in the future.
(In reply to Matthew Miller from comment #4) > Finally getting around to the review -- sorry. > > /usr/share/fedora-dockerfiles needs to be owned by the package (list %dir > %dir %{_datadir}/%{name} in the %files) > > Not necessary, but it might be cleaner to do the install part in a loop. Sure thing. I'll put up a new version after Scott updates upstream. > > Also: the auto-picked up deps on /bin/bash and /bin/sh are spurious, since > those scripts are executed inside the container. I think that making the > scripts not executable will fix that (although I'm not sure that the RUN > command will still work?). So maybe filter out the deps with RPM kludges -- > or else make whatever Dockerfile modifications are needed so the scripts can > be shipped nonexecutable. (That actually makes most sense to me because they > could theoretically actually be disastrous if run on the host accidentally.) So the current Dockerfiles seem to handle chmod +x by themselves so I think we can -x scripts by default. If that's agreeable, Scott please see my PR for -x on scripts on your github repo :) > > Question for Scott: do we want to do GPLv2 or a more permissive license? > Although it's some amount of overhead, it might be nice to clarify the > license specifically in each Dockerfile (or at least each subdirectory); > this gives us some room to use different possibly-conflicting licenses for > different contributions in the future.
(In reply to Matthew Miller from comment #4) > Finally getting around to the review -- sorry. > > /usr/share/fedora-dockerfiles needs to be owned by the package (list %dir > %dir %{_datadir}/%{name} in the %files) > > Not necessary, but it might be cleaner to do the install part in a loop. > > Also: the auto-picked up deps on /bin/bash and /bin/sh are spurious, since > those scripts are executed inside the container. I think that making the > scripts not executable will fix that (although I'm not sure that the RUN > command will still work?). So maybe filter out the deps with RPM kludges -- > or else make whatever Dockerfile modifications are needed so the scripts can > be shipped nonexecutable. (That actually makes most sense to me because they > could theoretically actually be disastrous if run on the host accidentally.) > > Question for Scott: do we want to do GPLv2 or a more permissive license? > Although it's some amount of overhead, it might be nice to clarify the > license specifically in each Dockerfile (or at least each subdirectory); > this gives us some room to use different possibly-conflicting licenses for > different contributions in the future. Good idea. I added GPLv2 to each subdirectory. Hopefully that'll work.
(In reply to Lokesh Mandvekar from comment #5) > (In reply to Matthew Miller from comment #4) > > Finally getting around to the review -- sorry. > > > > /usr/share/fedora-dockerfiles needs to be owned by the package (list %dir > > %dir %{_datadir}/%{name} in the %files) > > > > Not necessary, but it might be cleaner to do the install part in a loop. > > Sure thing. I'll put up a new version after Scott updates upstream. > > > > > Also: the auto-picked up deps on /bin/bash and /bin/sh are spurious, since > > those scripts are executed inside the container. I think that making the > > scripts not executable will fix that (although I'm not sure that the RUN > > command will still work?). So maybe filter out the deps with RPM kludges -- > > or else make whatever Dockerfile modifications are needed so the scripts can > > be shipped nonexecutable. (That actually makes most sense to me because they > > could theoretically actually be disastrous if run on the host accidentally.) > > So the current Dockerfiles seem to handle chmod +x by themselves so I think > we can -x scripts by default. > If that's agreeable, Scott please see my PR for -x on scripts on your github > repo :) > Done. > > > > > Question for Scott: do we want to do GPLv2 or a more permissive license? > > Although it's some amount of overhead, it might be nice to clarify the > > license specifically in each Dockerfile (or at least each subdirectory); > > this gives us some room to use different possibly-conflicting licenses for > > different contributions in the future.
%changelog * Tue Feb 11 2014 Lokesh Mandvekar <lsm5> 0-0.2.git7753bdf - use a loop to install stuff - include firefox and nodejs - install separate license for each program Spec URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/fedora-dockerfiles.spec SRPM URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/SRPMS/fedora-dockerfiles-0-0.2.git7753bdf.fc21.src.rpm BTW, there's this: $ rpmlint RPMS/noarch/fedora-dockerfiles-0-0.2.git7753bdf.fc21.noarch.rpm fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/mysql/start.sh 0644L /bin/bash fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/postgres/postgresql-setup 0644L /bin/sh fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/firefox/xstartup 0644L /bin/sh fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/postgres/start_postgres.sh 0644L /bin/bash fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/mysql/config_mysql.sh 0644L /bin/bash fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/wordpress_single_container/foreground.sh 0644L /bin/bash fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/wordpress_single_container/start.sh 0644L /bin/bash fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/postgres/postgres_user.sh 0644L /bin/bash fedora-dockerfiles.noarch: E: non-executable-script /usr/share/fedora-dockerfiles/ssh/start.sh 0644L /bin/bash 1 packages and 0 specfiles checked; 9 errors, 0 warnings. Can this be ignored, or should the install location be changed perhaps?
I think that can be ignored. I can't think of a better location, and they're really not _supposed_ to be executed.
oops -- need to own "/usr/share/fedora-dockerfiles"
%changelog * Wed Feb 19 2014 Lokesh Mandvekar <lsm5> 0-0.3.git7753bdf - own main package directory Spec URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/fedora-dockerfiles.spec SRPM URL: http://lsm5.fedorapeople.org/fedora-dockerfiles/SRPMS/fedora-dockerfiles-0-0.3.git7753bdf.fc21.src.rpm
Package review passed.
(In reply to Matthew Miller from comment #12) > Package review passed. Thanks Matt! New Package SCM Request ======================= Package Name: fedora-dockerfiles Short Description: Example dockerfiles to assist standing up containers quickly Owners: lsm5 Branches: f20 el6 epel7 InitialCC:
Git done (by process-git-requests).
fedora-dockerfiles-0-0.3.git7753bdf.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/fedora-dockerfiles-0-0.3.git7753bdf.el6
fedora-dockerfiles-0-0.3.git7753bdf.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedora-dockerfiles-0-0.3.git7753bdf.fc20
fedora-dockerfiles-0-0.3.git7753bdf.el6 has been pushed to the Fedora EPEL 6 testing repository.
fedora-dockerfiles-0-0.3.git7753bdf.fc20 has been pushed to the Fedora 20 stable repository.
fedora-dockerfiles-0-0.3.git7753bdf.el6 has been pushed to the Fedora EPEL 6 stable repository.