This is a new ebuild for the litmus project which is a powerfull WebDAV server protocol compliance test suite Reproducible: Always
Created attachment 350642 [details] litmus-0.13.ebuild
Also, available here: http://git.meleeweb.net/cgit.cgi/distros/gentoo/portage.git/log/www-misc/litmus
Comment on attachment 350642 [details] litmus-0.13.ebuild >src_install() { > emake install DESTDIR="${ED}" > > dodoc ChangeLog FAQ NEWS README THANKS TODO >} You can replace that entirely with DOCS=( ChangeLog FAQ NEWS README THANKS TODO ) since the default src_install already runs emake like that and because it also checks the DOCS variable and automatically runs dodoc on that.
(In reply to Jeroen Roovers from comment #3) > Comment on attachment 350642 [details] > litmus-0.13.ebuild > > >src_install() { > > emake install DESTDIR="${ED}" > > > > dodoc ChangeLog FAQ NEWS README THANKS TODO > >} > > You can replace that entirely with > > DOCS=( ChangeLog FAQ NEWS README THANKS TODO ) > > since the default src_install already runs emake like that and because it > also checks the DOCS variable and automatically runs dodoc on that. Thanks for the review. I can update this as your recommandation. I'm using it as I find src_install() more readable that header bash array. (Just a POV :)
Created attachment 350714 [details] litmus-0.13.ebuild Refresh as requested
> KEYWORDS="~amd64" Packages that work on ~amd64 will work on ~x86 in most of the cases; so, you can add ~x86 by default in the future to avoid the extra unnecessary work to keyword it, it makes more sense to mask or remove it when it breaks once it a lifetime. > IUSE="debug libproxy ssl" There were a lot more things optional, take a look at `./configure --help`. This became clear from the lines checking for support in the configure output. > DEPEND="|| ( dev-libs/libxml2 dev-libs/expat ) net-libs/neon[ssl?,zlib]" To avoid bumps of the dependencies from breaking the package, consider to slot the dependencies; that way when a major revision that will break it comes, it won't break building this package. For sub slot working and syntax, see `man 5 ebuild`; also see https://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators These additions and changes, amongst others that were the result from testing; I have applied to the ebuild, such that you can review them. The others were SSL support by either openssl or gnutls, limiting the version of neon, made sure neon is not built-in and restricting tests as they need a server. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-misc/litmus/ Once they are available, please take a look at both files on the above URL; if there is something particular you don't understand, feel free to ask about that. + 16 Aug 2013; Tom Wijsman <TomWij@gentoo.org> +litmus-0.13.ebuild, + +metadata.xml: + New package for www-misc/litmus, WebDAV server protocol compliance test + suite. Fixes bug #472878, proxied commit for Bertrand Jacquin (beber) who + will be the primary maintainer. Thank you for your contribution! :)
(In reply to Tom Wijsman (TomWij) from comment #6) > > KEYWORDS="~amd64" > > Packages that work on ~amd64 will work on ~x86 in most of the cases; so, you > can add ~x86 by default in the future to avoid the extra unnecessary work to > keyword it, it makes more sense to mask or remove it when it breaks once it > a lifetime. Apparently the above does not hold true (there is no unambiguous clear statement confirming it); I have asked the arch team for clarification and plan to discuss and or propose changes to this, I've been doing this for half a year and belief it spares out work. But until explicitly permitted I will stop doing so.
Created attachment 356434 [details, diff] litmus-0.13-v1.diff (In reply to Tom Wijsman (TomWij) from comment #6) > > KEYWORDS="~amd64" > > Packages that work on ~amd64 will work on ~x86 in most of the cases; so, you > can add ~x86 by default in the future to avoid the extra unnecessary work to > keyword it, it makes more sense to mask or remove it when it breaks once it > a lifetime. Even if I didn't test it ? > > IUSE="debug libproxy ssl" > > There were a lot more things optional, take a look at `./configure --help`. > > This became clear from the lines checking for support in the configure > output. That was primary a lazyness for functionality I will not use. > > DEPEND="|| ( dev-libs/libxml2 dev-libs/expat ) net-libs/neon[ssl?,zlib]" > > To avoid bumps of the dependencies from breaking the package, consider to > slot the dependencies; that way when a major revision that will break it > comes, it won't break building this package. For sub slot working and > syntax, see `man 5 ebuild`; also see > https://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators Interesting. > These additions and changes, amongst others that were the result from > testing; I have applied to the ebuild, such that you can review them. The > others were SSL support by either openssl or gnutls, limiting the version of > neon, made sure neon is not built-in and restricting tests as they need a > server. > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-misc/litmus/ > > Once they are available, please take a look at both files on the above URL; > if there is something particular you don't understand, feel free to ask > about that. This is clear. I was rewriting ebuild before seiing you already did. Here are some other thing I did. You will find attached a diff based on ebuild in tree. Replace manual SSL USE flag exclusion in REQUIRED_USE with more recent EAPI5 logic, and extend this to define the right ./configure option Handle expat or libxml2 as XML parser, each one exclude each other, and so define the right ./configure option Support threads. Fix pkcs11 DEPEND, dev-perl/GSSAPI can't be used as-is. The EGD is only usable in case of OpenSSL <= 0.9.7 if I read well. src_test must fail it you don't have any HTTP server supporting WebDAV locally, so use webdav servers from http://test.webdav.org/ (fail at the moment) Other thing, gssapi USE flag have been replaced with kerberos as this is global USE, and gssapi is often a synonym to kerberos. Does openssl local USE flag make sense when the global 'ssl' USE flag exist. Neon use that logic, 'ssl' for openssl, 'gnutls' for gnutls. Can't we make this ebuild more generic like this ?
Created attachment 356436 [details, diff] litmus-0.13-v2.diff Second shot with simplified DEPEND logic as neon and litmus DEPEND are quiet the same.
(In reply to Bertrand Jacquin from comment #8) > > Packages that work on ~amd64 will work on ~x86 in most of the cases; so, you > > can add ~x86 by default in the future to avoid the extra unnecessary work to > > keyword it, it makes more sense to mask or remove it when it breaks once it > > a lifetime. > > Even if I didn't test it ? No, sorry; my bad, made a wrong assumption in the early days. See Comment #7. > Replace manual SSL USE flag exclusion in REQUIRED_USE with more recent EAPI5 > logic, and extend this to define the right ./configure option Thanks; see, even after half a year I still learn new things. :) Next time I touch that variable I'll look at the handy table in `man 5 ebuild`. > Handle expat or libxml2 as XML parser, each one exclude each other, and so > define the right ./configure option The configure output automatically selects the one neon uses, I think. > src_test must fail it you don't have any HTTP server supporting WebDAV > locally, so use webdav servers from http://test.webdav.org/ (fail at the > moment) Yeah, it is sometimes somewhat problematic to get this to work properly; you also need to account for users with limited internet capabilities (their firewall might block the webdav connection), so, do what you can and otherwise just restrict it for someone else who really wants the tests. http://article.gmane.org/gmane.linux.gentoo.devel/78504 My thought was to introduce a test? ( ... ) dependency which depends on a server we could then run in src_test; but well, that is also completed and feels like overkill just to run a test. I think testing the package itself against those servers separate from src_test suffices as a test. A working src_test would just be "nice to have" if possible... > Other thing, gssapi USE flag have been replaced with kerberos as this is > global USE, and gssapi is often a synonym to kerberos. > > Does openssl local USE flag make sense when the global 'ssl' USE flag exist. > Neon use that logic, 'ssl' for openssl, 'gnutls' for gnutls. Can't we make > this ebuild more generic like this ? Yes, we can; I need to check these more often, now I remember the previous time someone pointed out that he had a neat trick and that is to do something like `qgrep -e \?.*openssl | sed -e "s/[\t ]//g" | sort | uniq -c | sort | tail` given that you have app-portage/portage-utils (for qgrep). (In reply to Bertrand Jacquin from comment #9) > Created attachment 356436 [details, diff] [details, diff] > litmus-0.13-v2.diff > > Second shot with simplified DEPEND logic as neon and litmus DEPEND are quiet > the same. We want ebuilds to explicitly depend on the dependencies they use instead of relying on another package to depend on them properly, there are two reasons: The dependency or dependencies a USE flag brings in might not be the ones you expect and might change; the other reason is that if you need to restrict by version, change SLOT or something else that the USE flags won't permit you to do that. I have taken a short look over the ebuild and will review / apply it later.
My 2 cents for this disscussion: iirc, QA team are usually against tests that requires internet connection. CCing them for clarification
(In reply to Tom Wijsman (TomWij) from comment #10) > > Handle expat or libxml2 as XML parser, each one exclude each other, and so > > define the right ./configure option > > The configure output automatically selects the one neon uses, I think. User may what to select one particulary, and that unsure litmus will not be linked to expat when unneeded/unwanted. As libxml2 is prefered of expat, that why I define +libxml2 in IUSE so it's selected by default. > > src_test must fail it you don't have any HTTP server supporting WebDAV > > locally, so use webdav servers from http://test.webdav.org/ (fail at the > > moment) > > Yeah, it is sometimes somewhat problematic to get this to work properly; you > also need to account for users with limited internet capabilities (their > firewall might block the webdav connection), so, do what you can and > otherwise just restrict it for someone else who really wants the tests. > > http://article.gmane.org/gmane.linux.gentoo.devel/78504 > > My thought was to introduce a test? ( ... ) dependency which depends on a > server we could then run in src_test; but well, that is also completed and > feels like overkill just to run a test. I think testing the package itself > against those servers separate from src_test suffices as a test. A working > src_test would just be "nice to have" if possible... I reverted to what you've made first as comment #11 recommend > > Other thing, gssapi USE flag have been replaced with kerberos as this is > > global USE, and gssapi is often a synonym to kerberos. > > > > Does openssl local USE flag make sense when the global 'ssl' USE flag exist. > > Neon use that logic, 'ssl' for openssl, 'gnutls' for gnutls. Can't we make > > this ebuild more generic like this ? > > Yes, we can; I need to check these more often, now I remember the previous > time someone pointed out that he had a neat trick and that is to do > something like `qgrep -e \?.*openssl | sed -e "s/[\t ]//g" | sort | uniq -c > | sort | tail` given that you have app-portage/portage-utils (for qgrep). Here 'ssl' USE flag win. So implemented. > (In reply to Bertrand Jacquin from comment #9) > > Created attachment 356436 [details, diff] [details, diff] [details, diff] > > litmus-0.13-v2.diff > > > > Second shot with simplified DEPEND logic as neon and litmus DEPEND are quiet > > the same. > > We want ebuilds to explicitly depend on the dependencies they use instead of > relying on another package to depend on them properly, there are two > reasons: > > The dependency or dependencies a USE flag brings in might not be the ones > you expect and might change; the other reason is that if you need to > restrict by version, change SLOT or something else that the USE flags won't > permit you to do that. I do understand, even if it complicate a bit more dependencies. But, why so it's not the same for 'zlib' USE flag ?
For your last comment, I think you have forgotten to attach a patch; anyhow, I have merged some of your suggested changes and adapted it to our last comments. + 01 Sep 2013; Tom Wijsman <TomWij@gentoo.org> litmus-0.13.ebuild, metadata.xml: + Use global USE flags, better REQUIRED_USE syntax and more cleanup; proxied + commit for Bertrand Jacquin, bug #472878. Let me know if I missed something, you think that something else needs to be changed or need explanation. Thank you for contributing and reviewing.
