Re: having the "+test" or "+tests" variant propagate causes unexpected builds
My own personal opinion has been that +test/+tests and +debug, by default, should not propagate through the chain of dependencies; and then perhaps there might be some way to enable propagation (maybe with a command line option?). However, if I recall correctly, all variants propagate through the dependency chain, so it might be difficult to make certain variant keywords behave differently? -- Jason Liu On Sun, Oct 23, 2022 at 1:58 PM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > Various ports implement a “test” or “tests” variant to allow extra > features and deps required for testing to be enabled. > > This variant, when requested, will propagate up the chain to all the > ports, however. There is no real use case where someone would desire the > test/s variant to propagate up. > > This generates needless builds, and often enables features people neither > need nor want, and then guarantees manual rebuilds, forever, of the > involved ports. > > I recently came back to a massive building project involving clang and > llvm when I was trying to build “mesa +tests”. Because clang-15 and llvm-15 > also have a “+tests” variant, and had not yet been installed, port was > building those (and possibly others) with the tests variant rather than use > the prebuilt binary. > > Of course I just aborted the huge llvm/clang-15 build, cleaned them up, > and installed them separately. But others would probably not know to do > this. > > I had suggested a few years ago we might namespace the test/tests > variants, by having a convention that the portname be prepended to the test > variant, to be more specific and avoid this — but not a widely acceptable > idea at that time. So we’re still in the same situation… > > Is it possible that a “test” or “tests” variant might not be propagated up > the ports chain by base, instead? > > > K > > > > PS. A similar thing happens with “+debug” variants, another common variant > that you *usually* don’t want propagated up to *every single port* in the > chain either. > > This one is occasionally something that people would want up their chain, > but it is so fragile of a plan to rely on variant propagation (ie if you > have the port installed already, it won’t be reinstalled with the “+debug” > variant), that such rare users might best install each port they want to be > installed as “debug” do that specifically. Certainly most of us don’t want > clang-15 installed with it’s debug variant when you’re trying to debug some > little port.
having the "+test" or "+tests" variant propagate causes unexpected builds
Various ports implement a “test” or “tests” variant to allow extra features and deps required for testing to be enabled. This variant, when requested, will propagate up the chain to all the ports, however. There is no real use case where someone would desire the test/s variant to propagate up. This generates needless builds, and often enables features people neither need nor want, and then guarantees manual rebuilds, forever, of the involved ports. I recently came back to a massive building project involving clang and llvm when I was trying to build “mesa +tests”. Because clang-15 and llvm-15 also have a “+tests” variant, and had not yet been installed, port was building those (and possibly others) with the tests variant rather than use the prebuilt binary. Of course I just aborted the huge llvm/clang-15 build, cleaned them up, and installed them separately. But others would probably not know to do this. I had suggested a few years ago we might namespace the test/tests variants, by having a convention that the portname be prepended to the test variant, to be more specific and avoid this — but not a widely acceptable idea at that time. So we’re still in the same situation… Is it possible that a “test” or “tests” variant might not be propagated up the ports chain by base, instead? K PS. A similar thing happens with “+debug” variants, another common variant that you *usually* don’t want propagated up to *every single port* in the chain either. This one is occasionally something that people would want up their chain, but it is so fragile of a plan to rely on variant propagation (ie if you have the port installed already, it won’t be reinstalled with the “+debug” variant), that such rare users might best install each port they want to be installed as “debug” do that specifically. Certainly most of us don’t want clang-15 installed with it’s debug variant when you’re trying to debug some little port.
Re: Selfupdate to MacPorts 2.8.0 Throws Error 'Couldn't change permissions of the MacPorts sources'
Hi, Already reported. See https://lists.macports.org/pipermail/macports-users/2022-October/051518.html which includes a link to https://trac.macports.org/ticket/66031 Chris > On 22 Oct 2022, at 1:09 pm, Steven Smith wrote: > I’m consistently getting this error across multiple boxes when doing a > selfupdate to 2.8.0: > >> Congratulations, you have successfully upgraded the MacPorts system. >> >> Error: Couldn't change permissions of the MacPorts sources at >> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base >> to root: child killed: kill signal > > Another selfupdate command ignores the issue, but the ownership of base > appears to be broken: > >> ls -ld >> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base >> drwxr-xr-x 35 messagebus polkitd 1120 Oct 22 07:57 >> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base/
