Re: mpkg package variants
On Oct 6, 2019, at 07:55, Werner LEMBERG wrote: I believe you can just specify the variants that you want (for the port and all of its dependencies) at the command line when you run `port mpkg`, can't you? As in: sudo port mpkg lilypond-devel +mactex +perl5_28 >>> >>> This seems to work, thanks! Maybe it's worth to document that. >> >> Surely it's already documented that variants you specify are passed >> down to any dependencies that get built (but not to any that don't >> need to be built)? > > If it is, I have missed that. As I've said before, the guide needs to be thrown out and rewritten from scratch. But... it does say "MacPorts will also use the specified variants for any dependencies": https://guide.macports.org/#using.variants.invoking >> But maybe it is worth mentioning that for mpkg, all packages get >> rebuilt, so the specified variants are applied to all of the ports, >> even those that were already installed (if that's not already >> mentioned in the guide). > > It's either missing or I have missed that, too :-) I don't see any mention of it here: https://guide.macports.org/#using.binaries.binary-packages The guide sources are here if anyone wants to contribute an improvement: https://github.com/macports/macports-guide/ >>> Of course, the next question is whether MacPorts variant strings >>> form a consistent set without contradictions. >> >> What does that mean? > > Since MacPorts contains thousands of packages there might be a clash > somewhere in the variant names. Assuming that package X needs > `+foo' and package Y needs `-foo', I would have to specify > > mpkg ... +foo -foo > > which obviously doesn't work. Right, that wouldn't work. Port authors can of course name variants as they choose and define them to do anything, so the situation you propose is theoretically possible, but I don't think you'll encounter it. If you do, file a bug report and maybe something can be changed. >> As for test files, if you mean tests that get run by the `port test` >> command, then I would not expect those to be installed by a port; >> they would be used at test time and would not be needed afterwards. > > I'm not sure about the `port test` thing, but the python 2.7 and 3.7 > bundles contains zillions of files in directories > > .../Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test > .../Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest > > and > > .../Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test > .../Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest > > Are these files of any use after installation? I am not very familiar with python, but my guess is that they must be useful, otherwise nobody would have written code to install them. A quick search suggests that unittest, for example, is a unit testing framework that python modules might use in implementing their own tests: https://docs.python.org/2/library/unittest.html
Re: mpkg package variants
>>> I believe you can just specify the variants that you want (for the >>> port and all of its dependencies) at the command line when you run >>> `port mpkg`, can't you? As in: >>> >>> sudo port mpkg lilypond-devel +mactex +perl5_28 >> >> This seems to work, thanks! Maybe it's worth to document that. > > Surely it's already documented that variants you specify are passed > down to any dependencies that get built (but not to any that don't > need to be built)? If it is, I have missed that. > But maybe it is worth mentioning that for mpkg, all packages get > rebuilt, so the specified variants are applied to all of the ports, > even those that were already installed (if that's not already > mentioned in the guide). It's either missing or I have missed that, too :-) >> Of course, the next question is whether MacPorts variant strings >> form a consistent set without contradictions. > > What does that mean? Since MacPorts contains thousands of packages there might be a clash somewhere in the variant names. Assuming that package X needs `+foo' and package Y needs `-foo', I would have to specify mpkg ... +foo -foo which obviously doesn't work. >> Another issue: There are many files in the mpkg file that are >> definitely unnecessary to run the final program (in my case the >> `lilypond' binary from `lilypond-devel'), for example test files >> for python, or header files of C libraries, or (most of the) >> documentation. Is there any support from `port' to not package >> that? > > MacPorts ports always install header files where possible. Many > ports also install examples or documentation. If these files are > unwanted in your package, you may need to manually edit the package > after it's been made. OK, thanks. This was my conclusion, too. > As for test files, if you mean tests that get run by the `port test` > command, then I would not expect those to be installed by a port; > they would be used at test time and would not be needed afterwards. I'm not sure about the `port test` thing, but the python 2.7 and 3.7 bundles contains zillions of files in directories .../Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test .../Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest and .../Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test .../Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest Are these files of any use after installation? Werner
Re: mpkg package variants
On Oct 5, 2019, at 11:36, Werner LEMBERG wrote: >>> Let me reformulate my question: Does the way how I have installed >>> MacPorts packages on my computer influence how `port mpkg' works >>> for a given package? Given that `port mpkg' rebuilds all packages, >>> I would expect no. Instead, I would expect some control file (or a >>> special command line sequence) to control variants of package >>> dependencies. >> >> I believe you can just specify the variants that you want (for the >> port and all of its dependencies) at the command line when you run >> `port mpkg`, can't you? As in: >> >> sudo port mpkg lilypond-devel +mactex +perl5_28 > > This seems to work, thanks! Maybe it's worth to document that. Surely it's already documented that variants you specify are passed down to any dependencies that get built (but not to any that don't need to be built)? But maybe it is worth mentioning that for mpkg, all packages get rebuilt, so the specified variants are applied to all of the ports, even those that were already installed (if that's not already mentioned in the guide). > Of course, the next question is whether MacPorts variant strings form > a consistent set without contradictions. What does that mean? > Another issue: There are many files in the mpkg file that are > definitely unnecessary to run the final program (in my case the > `lilypond' binary from `lilypond-devel'), for example test files for > python, or header files of C libraries, or (most of the) > documentation. Is there any support from `port' to not package that? MacPorts ports always install header files where possible. Many ports also install examples or documentation. If these files are unwanted in your package, you may need to manually edit the package after it's been made. As for test files, if you mean tests that get run by the `port test` command, then I would not expect those to be installed by a port; they would be used at test time and would not be needed afterwards.
Re: mpkg package variants
>> Let me reformulate my question: Does the way how I have installed >> MacPorts packages on my computer influence how `port mpkg' works >> for a given package? Given that `port mpkg' rebuilds all packages, >> I would expect no. Instead, I would expect some control file (or a >> special command line sequence) to control variants of package >> dependencies. > > I believe you can just specify the variants that you want (for the > port and all of its dependencies) at the command line when you run > `port mpkg`, can't you? As in: > > sudo port mpkg lilypond-devel +mactex +perl5_28 This seems to work, thanks! Maybe it's worth to document that. Of course, the next question is whether MacPorts variant strings form a consistent set without contradictions. Another issue: There are many files in the mpkg file that are definitely unnecessary to run the final program (in my case the `lilypond' binary from `lilypond-devel'), for example test files for python, or header files of C libraries, or (most of the) documentation. Is there any support from `port' to not package that? Werner
Re: mpkg package variants
On Sep 29, 2019, at 08:57, Werner LEMBERG wrote: > Let me reformulate my question: Does the way how I have installed > MacPorts packages on my computer influence how `port mpkg' works for a > given package? Given that `port mpkg' rebuilds all packages, I would > expect no. Instead, I would expect some control file (or a special > command line sequence) to control variants of package dependencies. > > Is this flawed thinking? I believe you can just specify the variants that you want (for the port and all of its dependencies) at the command line when you run `port mpkg`, can't you? As in: sudo port mpkg lilypond-devel +mactex +perl5_28
Re: mpkg package variants
>> I wonder how package variants are handled while creating `mpkg' >> bundles. As an example, consider the output of >> >> port rdeps lilypond-devel +mactex >> >> Looking at it you can see >> >> ... >> ossp-uuid >> perl5.26 >> ... >> >> and >> >> ... >> llvm-3.4 >> perl5 >> perl5.28 >> ... >> >> The created `mpgk-packages' directory indeed contains both perl >> 5.26 and 5.28. >> >> However, it is possible to install `ossp-uuid' as >> >> port install ossp-uuid +perl5_28 >> >> In other words, it would be possible to omit a dependency on >> `perl5.26' altogether. What must I do to enforce this for `port >> mpkg'? This would reduce the size of the bundle by approx >> 16MByte... > > On my machine "port info ossp-uuid" says that default in 5.28 now, > but you might have installed it when 5.26 was still the default, so > I'm not quite sure what goes wrong here (does installing with 5.28 > variant help?). I did install `ossp-uuid' with 5.28, but a new run of `port mpkg' (without a `port clean', though) gives the same result. Let me reformulate my question: Does the way how I have installed MacPorts packages on my computer influence how `port mpkg' works for a given package? Given that `port mpkg' rebuilds all packages, I would expect no. Instead, I would expect some control file (or a special command line sequence) to control variants of package dependencies. Is this flawed thinking? Werner
Re: mpkg package variants
On Sat, 28 Sep 2019 at 20:49, Werner LEMBERG wrote: > > > Folks, > > > I wonder how package variants are handled while creating `mpkg' > bundles. As an example, consider the output of > > port rdeps lilypond-devel +mactex > > Looking at it you can see > > ... > ossp-uuid > perl5.26 > ... > > and > > ... > llvm-3.4 > perl5 > perl5.28 > ... > > The created `mpgk-packages' directory indeed contains both perl 5.26 > and 5.28. > > However, it is possible to install `ossp-uuid' as > > port install ossp-uuid +perl5_28 > > In other words, it would be possible to omit a dependency on > `perl5.26' altogether. What must I do to enforce this for `port > mpkg'? This would reduce the size of the bundle by approx 16MByte... On my machine "port info ossp-uuid" says that default in 5.28 now, but you might have installed it when 5.26 was still the default, so I'm not quite sure what goes wrong here (does installing with 5.28 variant help?). By far the best bet would be to remove 5.26 from this port and all its dependents (or all ports, for that matter). We need some help finishing https://trac.macports.org/ticket/58361 (or maybe even go straight to 5.30 :). Mojca
mpkg package variants
Folks, I wonder how package variants are handled while creating `mpkg' bundles. As an example, consider the output of port rdeps lilypond-devel +mactex Looking at it you can see ... ossp-uuid perl5.26 ... and ... llvm-3.4 perl5 perl5.28 ... The created `mpgk-packages' directory indeed contains both perl 5.26 and 5.28. However, it is possible to install `ossp-uuid' as port install ossp-uuid +perl5_28 In other words, it would be possible to omit a dependency on `perl5.26' altogether. What must I do to enforce this for `port mpkg'? This would reduce the size of the bundle by approx 16MByte... Werner
