Re: [28060] trunk/dports/archivers/sharutils/Portfile
On Aug 19, 2007, at 11:31, source_changes@macosforge.org wrote:
Revision: 28060 http://trac.macosforge.org/projects/macports/changeset/28060 Author: nox@macports.org Date: 2007-08-19 09:31:54 -0700 (Sun, 19 Aug 2007)
Log Message: ----------- sharutils: * Updated to 4.7. * NLS support is now a variant.
Why, by the way? Do you believe most people will not want native language support? There's a lot of software with NLS, and I think most of it is on by default. Do you propose going through all of them to make NLS off by default? Why is this desirable? Why should we spend time on this? All it does, in the end, is give the user yet another choice they need to make. Our goal should not be to give the user every conceivable choice, but to use our expertise to choose a reasonable configuration for the user.
* libiconv has been added to the NLS dependencies. * Fixed livecheck. * Added doc installation.
Modified Paths: -------------- trunk/dports/archivers/sharutils/Portfile
Modified: trunk/dports/archivers/sharutils/Portfile =================================================================== --- trunk/dports/archivers/sharutils/Portfile 2007-08-19 16:31:39 UTC (rev 28059) +++ trunk/dports/archivers/sharutils/Portfile 2007-08-19 16:31:54 UTC (rev 28060) @@ -3,7 +3,7 @@ PortSystem 1.0
name sharutils -version 4.6.3 +version 4.7 categories archivers maintainers nomaintainer description Shell archiver utilities @@ -17,20 +17,38 @@ files, split long files and construct multi-part mailings, ensure \ correct unsharing order, and provide simplistic checksums.
+homepage http://www.gnu.org/software/${name}/ master_sites gnu:${name}/REL-${version} -homepage http://www.gnu.org/software/${name}/ use_bzip2 yes
-checksums md5 ec4c932d0704efe288d82219b089a3dc \ - sha1 a036736307b814695ca68d04c465fdc4e5889218 \ - rmd160 3beb2c202610d65d8df1e9ea585cfcb28dcb9897 +checksums md5 729c070d814d9c688489d88dd7fd3efb \ + sha1 0b8c1d54fdcf97a93aba079d342d1873a8fc423b \ + rmd160 6ef271d21ea41003ff13d6aef241c6a4fd4dc296
-depends_lib port:gettext - configure.args-append --mandir=${prefix}/share/man \ - --infodir=${prefix}/share/info + --infodir=${prefix}/share/info \ + --disable-nls
+set docdir ${prefix}/share/doc/${name}-${version} + +post-destroot { + xinstall -d ${destroot}${docdir} + xinstall -m 0644 -W ${worksrcpath} AUTHORS COPYING ChangeLog NEWS README THANKS TODO \ + ${destroot}${docdir} +} + +variant nls description {Enable NLS support} {
I think the name of the variant ("nls") makes it pretty clear that it "Enable[s] NLS"; the person who needs to read the description, however, is the one who doesn't know what "NLS" stands for. If this variant is retained, the description should be more helpful. FYI, since "NLS" stands for native (or natural) language support, "NLS support" is just as redundant as "ATM machine" or "PIN number". :-)
+ depends_lib-append port:gettext \ + port:libiconv + + configure.args-delete --disable-nls + + post-destroot { + xinstall -m 0644 ${worksrcpath}/ABOUT-NLS ${destroot}${docdir} + } +} + livecheck.check regex -livecheck.url http://ftp.gnu.org/gnu/sharutils/REL-${version}/ -livecheck.regex ${name}-(\\d+(?:\\.\\d+)*) +livecheck.url http://ftp.gnu.org/gnu/sharutils/?M=D +livecheck.regex REL-(\\d+(?:\\.\\d+)*)
Le 19 août 07 à 22:42, Ryan Schmidt a écrit :
On Aug 19, 2007, at 11:31, source_changes@macosforge.org wrote:
Revision: 28060 http://trac.macosforge.org/projects/macports/changeset/ 28060 Author: nox@macports.org Date: 2007-08-19 09:31:54 -0700 (Sun, 19 Aug 2007)
Log Message: ----------- sharutils: * Updated to 4.7. * NLS support is now a variant.
Why, by the way? Do you believe most people will not want native language support? There's a lot of software with NLS, and I think most of it is on by default. Do you propose going through all of them to make NLS off by default? Why is this desirable? Why should we spend time on this? All it does, in the end, is give the user yet another choice they need to make. Our goal should not be to give the user every conceivable choice, but to use our expertise to choose a reasonable configuration for the user.
I think NLS should be a variant in every port, then it could be able to enable it if you want. This would be a reasonable configuration setting for the user.
+variant nls description {Enable NLS support} {
I think the name of the variant ("nls") makes it pretty clear that it "Enable[s] NLS"; the person who needs to read the description, however, is the one who doesn't know what "NLS" stands for. If this variant is retained, the description should be more helpful.
FYI, since "NLS" stands for native (or natural) language support, "NLS support" is just as redundant as "ATM machine" or "PIN number". :-)
Thanks, i'll change this. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On Aug 19, 2007, at 17:06, N_Ox wrote:
Le 19 août 07 à 22:42, Ryan Schmidt a écrit :
On Aug 19, 2007, at 11:31, source_changes@macosforge.org wrote:
Revision: 28060 http://trac.macosforge.org/projects/macports/changeset/ 28060 Author: nox@macports.org Date: 2007-08-19 09:31:54 -0700 (Sun, 19 Aug 2007)
Log Message: ----------- sharutils: * Updated to 4.7. * NLS support is now a variant.
Why, by the way? Do you believe most people will not want native language support? There's a lot of software with NLS, and I think most of it is on by default. Do you propose going through all of them to make NLS off by default? Why is this desirable? Why should we spend time on this? All it does, in the end, is give the user yet another choice they need to make. Our goal should not be to give the user every conceivable choice, but to use our expertise to choose a reasonable configuration for the user.
I think NLS should be a variant in every port, then it could be able to enable it if you want. This would be a reasonable configuration setting for the user.
But again, why? It sounds like you're proposing quite a lot of effort for something that will in the end be nothing but an inconvenience. My rough estimate is that over 500 ports depend on gettext at this time. You're proposing that all those portfiles be modified to include a new variant for gettext support, and having it off by default. All those ports will need to be tested to ensure the port works correctly with and without that variant. Since the installed product will be different, the revision of each port will have to be incremented. Anyone who has those ports installed will therefore be made to rebuild them, costing everyone time. And the end result of all this effort is that gettext support is removed from those ports. For those who do not use NLS, nothing will change -- no benefit, no detriment. For those who do use NLS, only detriment will occur -- they will lose NLS and will have to uninstall the ports and reinstall them with the +nls variant to get it back. I don't see why this is desirable.
Le 20 août 07 à 03:08, Ryan Schmidt a écrit :
On Aug 19, 2007, at 17:06, N_Ox wrote:
Le 19 août 07 à 22:42, Ryan Schmidt a écrit :
On Aug 19, 2007, at 11:31, source_changes@macosforge.org wrote:
Revision: 28060 http://trac.macosforge.org/projects/macports/changeset/ 28060 Author: nox@macports.org Date: 2007-08-19 09:31:54 -0700 (Sun, 19 Aug 2007)
Log Message: ----------- sharutils: * Updated to 4.7. * NLS support is now a variant.
Why, by the way? Do you believe most people will not want native language support? There's a lot of software with NLS, and I think most of it is on by default. Do you propose going through all of them to make NLS off by default? Why is this desirable? Why should we spend time on this? All it does, in the end, is give the user yet another choice they need to make. Our goal should not be to give the user every conceivable choice, but to use our expertise to choose a reasonable configuration for the user.
I think NLS should be a variant in every port, then it could be able to enable it if you want. This would be a reasonable configuration setting for the user.
But again, why? It sounds like you're proposing quite a lot of effort for something that will in the end be nothing but an inconvenience.
My rough estimate is that over 500 ports depend on gettext at this time. You're proposing that all those portfiles be modified to include a new variant for gettext support, and having it off by default. All those ports will need to be tested to ensure the port works correctly with and without that variant. Since the installed product will be different, the revision of each port will have to be incremented. Anyone who has those ports installed will therefore be made to rebuild them, costing everyone time. And the end result of all this effort is that gettext support is removed from those ports. For those who do not use NLS, nothing will change -- no benefit, no detriment. For those who do use NLS, only detriment will occur -- they will lose NLS and will have to uninstall the ports and reinstall them with the +nls variant to get it back. I don't see why this is desirable.
There's 189 ports depending on gettext, roughly 20 of them depends on it through a variant, there's not _that_ much work to made NLS a variant. IMHO, your so-called reasonable configuration for the user should be a wise-thought variants.conf, with comments about the global variants user should be interested in. About testing the port, don't tell me NLS is a cricital feature that requires a lot of expensive tests, we all know this is just a matter of a configure flag, 2 links against libiconv and libintl and a bunch of installed locale files. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org
On Aug 20, 2007, at 9:10 AM, N_Ox wrote:
About testing the port, don't tell me NLS is a cricital feature that requires a lot of expensive tests, we all know this is just a matter of a configure flag, 2 links against libiconv and libintl and a bunch of installed locale files.
Default builds for ports should support as much as is reasonably possible. It makes sense to include NLS support by default in most ports. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On Aug 20, 2007, at 8:17 AM, Rainer Müller wrote:
Daniel J. Luke wrote:
It makes sense to include NLS support by default in most ports.
I would like +nls variants, so people who want localized software could enable this in variants.conf.
I don't see any advantage to adding complexity here. I believe we should write something like this up in the guide: The default installation of the software should be as feature complete, out of the box, as is possible. Variants should only be used for enabling incompatible options, or *expensive* features that most individuals will not need.
On 21/08/2007, at 02:55, Landon Fuller wrote:
I don't see any advantage to adding complexity here. I believe we should write something like this up in the guide: The default installation of the software should be as feature complete, out of the box, as is possible. Variants should only be used for enabling incompatible options, or *expensive* features that most individuals will not need.
+1 from me. As I understand it, the design philosophy of MacPorts from the beginning was "Principle of Least Surprise", and that went for the ports as well as the core MacPorts code. I can't imagine many things more frustrating to an ordinary user than installing a program that they thought had localised text, which they wanted because their English wasn't that strong, only to discover that it didn't install that way by default. The same thing goes for other usual features that can optionally be disabled. The more knowledgable users amongst us can always turn off things we don't want or need; the same can't be said for less advanced users trying to find out how to turn _on_ things that they want or need (though for some reasons, like security, it may be prudent to try to save users from themselves). Now I don't mean to say that I don't like Rainer's other idea of being able to set MacPorts-wide variant options; that actually appeals to me a lot. Such a mechanism, however, is orthogonal to the concern at hand, which is about what should be enabled by default, and I agree with Landon on that. I can't help but think that that sort of thinking goes a long way towards the reputation for ease of use enjoyed by Mac OS and the software that runs on it, and I for one would want to avoid denting that as much as possible. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org
participants (6)
-
Boey Maun Suang
-
Daniel J. Luke
-
Landon Fuller
-
N_Ox
-
Rainer Müller
-
Ryan Schmidt