Re: Dependencies on non-default variants
ny ports; if the user has already installed ports, the > user should uninstall them if switching from +x11 to +quartz or vice-versa. > There's currently no functionality in MacPorts base that would automate > uninstalling and reinstalling all ports. So I don't see how we could switch > the default variants of ports from +x11 to +quartz without breaking existing > users' installations. > In my made-up example, 80% of users had the non-default variant selected. At some point, would not the convenience of the great majority outweigh some easily fixed breakage for the minority of users? > >> I believe there is a very, very old ticket on this issue but I can’t find it >> right now. > > Do you mean https://trac.macports.org/ticket/126 ? I'm on record there and > elsewhere opposing adding support for dependencies on variants. I understand > how in extremely limited specific cases it could be useful, but I don't see > how it can work if we consider the problem just a little further. > > Currently, mythtv-core.28 requires p5.26-dbd-mysql with the mariadb variant. > If the user does not already have p5.26-dbd-mysql installed, we could > possibly improve MacPorts so that it automatically installs p5.26-dbd-mysql > with the mariadb variant when mythtv-core.28 is installed. But what if the > user has already installed p5.26-dbd-mysql with a different variant such as > mariadb10_2? Presumably they did so for a reason: Presumably they already > have a MariaDB 10.2 server set up and they want to use it from Perl. If they > now try to install mythtv-core.28, they can't, unless they forgo being able > to access their MariaDB 10.2 server from Perl 5.26. That restriction > shouldn't exist. > Seems like a use for the interactive feature added to base a few years ago. If the user has a conflicting variant installed, we could explain the situation and ask the user’s decision. By ‘explain’, we could check if the conflicting variant is used by another active and requested port and show what might be broken by switching to the now-desired variant. > >>>> And if we can implement a workaround, why can’t we share it with this >>>> other page? >>> >>> Because I don't want to implement "build is both working and broken at >>> the same time" functionality in buildbot. >>> >> I never said to report that the build is “working”. >> >> I suggested that we report that the build was not attempted which is exactly >> what happened. > > Currently, when our buildbot encounters a port that requires dependencies > with non-default variants, what happens is that a build for that port is > scheduled, and then that build fails because the dependencies are not > installed with the required variants. I agree with Mojca that we should not > spend a great deal of time and effort implementing special support in a web > app for identifying and reporting this specific type of failure. > > Instead, we might implement a solution similar to what we already do for > graveyard and obsolete ports, which is that we don't schedule a build for > those ports at all. Difficulty #1 would be in extracting the list of required > and forbidden variants from the Portfile: Since there is no MacPorts base > support for this, they would be expressed in terms of the active_variants 1.1 > portgroup; we may have to parse the Portfile code directly. Difficulty #2 > would be in identifying in advance which variants the dependencies would be > installed with. > > More generally, I have previously argued that MacPorts should have a keyword > that can be set from Portfiles or portgroups to indicate that a port is > expected to fail to build; the port or portgroup could set this conditionally > based on whatever criteria it needs to (OS version, Xcode version, variants > of dependencies, etc.). If we had this, it would be trivial for the buildbot > to check that variable before scheduling a build. For some reason, others > didn't seem to like this proposal and I don't think any code was written for > it. Yes, I have saved emails from August 2016 where there was discussion of exactly these issues. Sometimes we seem to get bogged down waiting for years for a pure and elegant solution when a simple and expedient solution would solve much of the pain right now. OTOH, I don’t have the time or skills to contribute to base so it is easy for me to lob in suggestions. Craig
Re: Dependencies on non-default variants
d p5.26-dbd-mysql with a different variant such as mariadb10_2? Presumably they did so for a reason: Presumably they already have a MariaDB 10.2 server set up and they want to use it from Perl. If they now try to install mythtv-core.28, they can't, unless they forgo being able to access their MariaDB 10.2 server from Perl 5.26. That restriction shouldn't exist. >>> And if we can implement a workaround, why can’t we share it with this other >>> page? >> >> Because I don't want to implement "build is both working and broken at >> the same time" functionality in buildbot. >> > I never said to report that the build is “working”. > > I suggested that we report that the build was not attempted which is exactly > what happened. Currently, when our buildbot encounters a port that requires dependencies with non-default variants, what happens is that a build for that port is scheduled, and then that build fails because the dependencies are not installed with the required variants. I agree with Mojca that we should not spend a great deal of time and effort implementing special support in a web app for identifying and reporting this specific type of failure. Instead, we might implement a solution similar to what we already do for graveyard and obsolete ports, which is that we don't schedule a build for those ports at all. Difficulty #1 would be in extracting the list of required and forbidden variants from the Portfile: Since there is no MacPorts base support for this, they would be expressed in terms of the active_variants 1.1 portgroup; we may have to parse the Portfile code directly. Difficulty #2 would be in identifying in advance which variants the dependencies would be installed with. More generally, I have previously argued that MacPorts should have a keyword that can be set from Portfiles or portgroups to indicate that a port is expected to fail to build; the port or portgroup could set this conditionally based on whatever criteria it needs to (OS version, Xcode version, variants of dependencies, etc.). If we had this, it would be trivial for the buildbot to check that variable before scheduling a build. For some reason, others didn't seem to like this proposal and I don't think any code was written for it.
Re: Dependencies on non-default variants
On Mar 25, 2019, at 01:56, Mojca Miklavec wrote: > would prefer if he or she would perhaps spend time adding novel > functionality, which could even be allowing user comments on each port > (which you could use to explain why the port appears to be broken) The ability to add comments on web pages is usually terrible. At best, you'll get a user adding a comment providing a useful recommendation or helpful tip. But I expect the majority of comments would actually be spam (which we would have to delete) or bug reports. Instead of implementing comments, we should refer users to existing support channels like the mailing lists and issue tracker. A list of open tickets and PRs for this port could even be shown on the page.
Re: Dependencies on non-default variants (was: GSoC 2019 [Collect build statistics])
Mojca:
I apologize for the length of this and for continuing to hammer on this issue
but I think this is important. I support the idea of a modern web app to bring
together all the relevant information for a port that potential users of
MacPorts need in order to assess if they want to install that software. The
results of the last buildbot runs is obviously valuable information. We would
expect that virtually all ports would report successful builds on all the OS
versions that they support. As a maintainer, I wouldn’t leave a port in a
broken state if I could possibly help it.
A port that requires non-default variants is not known to be broken. It did
not fail to build—the buildbot was unable to attempt a build. The vast
majority of the time, it will build and install just fine for the user.
> On Mar 24, 2019, at 4:05 PM, Mojca Miklavec wrote:
>
> On Sun, 24 Mar 2019 at 19:55, Craig Treleaven wrote:
>>> On Mar 24, 2019, at 1:09 PM, Mojca Miklavec wrote:
>>> On Sun, 24 Mar 2019 at 01:06, Craig Treleaven wrote:
> […]
> I now checked the first two random MythTV ports, which basically boils down
> to:
>
> require_active_variants qt5-mysql-plugin mariadb55
> require_active_variants p${perl5.major}-dbd-mysql mariadb
> require_active_variants ${pymodver}-mysql mariadb55
>
> out of which only the second one provides the wrong default variant,
> and that port doesn't have the maintainer. Neither do any of the mysql
> packages have any maintainer at the moment.
>
> My first question is: why exactly does p5-dbd-mysql need a different
> default variant?
>
Myth requires a database backend and I’ve chosen mariadb 5.5. I was pushed to
add variants for mysql and different db versions. That would have been a
nightmare to support. The perl dbd-mysql modules have to know where to find
the db socket (AIUI) and therefore need a different variant depending on which
database/version they are connecting to. I’ve documented the required variants
in the cookbook instructions on the MythTV wiki.
If I change the default variant for p5-dbd-mysql to suit me, I just push the
problem to someone else. I have no idea how many others are using this port
and depend on it connecting to MySQL 5.7 by default.
BTW, mythtv-core.28, for example, doesn’t support OS X 10.8 or earlier. It
“fails” to build on those buildbots although it actually aborts before
attempting the build. I’m fine with that being reported in the web app as a
failure since users of those OS versions will be informed that they can’t
expect it to build for them. I don’t want users on supported OS versions to
see the exact same failure message. “Unable to attempt” or “Not attempted” is
actually what happened.
More generally, a relatively common issue on MacPorts is X11 versus Quartz. Say
the support library (such as gtk2) defaults to one (like +x11) but your package
really needs the other. Changing the default messes up others. BTW, this
would be a compelling use of installation statistics. If we determined that,
say, 80% of gtk2 installs are +quartz, then it would be a no-brainer to change
the default.
> My second question / suggestion: please try to take over maintenance
> of the packages that you depend on and turn them into a shape that
> will make them more generally usable.
>
It is outside my skill set and beyond the time I have available for MacPorts.
Our database ports and related accessors need someone with more knowledge of
database admin than I have or want to have. They are big, complex pieces of
software and maintaining our fleet of ports is a serious commitment. (Bradley,
I miss you!)
> On Mar 25, 2019, at 2:56 AM, Mojca Miklavec wrote:
>
> Dear Craig,
>
>> As you said, people have looked at this problem and not found a workable
>> solution.
>
> Personally I never did spend any effort into fixing this, partially
> probably also because it doesn't affect any ports that I use or
> maintain.
>
I believe there is a very, very old ticket on this issue but I can’t find it
right now.
>> It may be a _long_ time before a “proper” solution is implemented.
>
> You don't need a 100% perfect solution, but something that works.
>
> What buildbot setup could do, is check which variants are required for
> a particular port. It could then perhaps install
>p5.28-dbd-mysql +mariadb
> explicitly, which could at least work for direct dependencies; getting
> it to work correctly in a recursive way would be a bigger challenge.
>
> Again, by far the easiest solution would be to fix ports in a way that
> no port requires a non-default variant to be active. You didn't yet
> answer my question: what prevents the dependencies of MythTV to change
> their default variants, so that your ports would work out of the box?
>
See above.
>> In the meantime, reporting these as failed builds *actively misinforms*
>> users.
>
> This has been the case for years already.
>
>> When you say there will be the same
Re: Dependencies on non-default variants (was: GSoC 2019 [Collect build statistics])
Dear Craig, > As you said, people have looked at this problem and not found a workable > solution. Personally I never did spend any effort into fixing this, partially probably also because it doesn't affect any ports that I use or maintain. > It may be a _long_ time before a “proper” solution is implemented. You don't need a 100% perfect solution, but something that works. What buildbot setup could do, is check which variants are required for a particular port. It could then perhaps install p5.28-dbd-mysql +mariadb explicitly, which could at least work for direct dependencies; getting it to work correctly in a recursive way would be a bigger challenge. Again, by far the easiest solution would be to fix ports in a way that no port requires a non-default variant to be active. You didn't yet answer my question: what prevents the dependencies of MythTV to change their default variants, so that your ports would work out of the box? > In the meantime, reporting these as failed builds *actively misinforms* users. This has been the case for years already. > When you say there will be the same problem “on a different page”, I don’t > know what you mean. One of the project ideas is to make buildbot logs and summaries more useful, directly from the buildbot views: https://trac.macports.org/ticket/55978 While we could internally waste weeks doing ugly workarounds to make some ports artificially look pretty, I'm not going to ask developers of buildbot to implement workarounds to allow cheating and report the same build as both broken and successful at the same time. If you don't want your port to be reported as broken, fix either the port(s), the base, or the buildbot configuration. An example of a buildbot configuration fix (that didn't actually take a lot of time to do) is that we no longer build obsolete ports (we used to do that in the past and got zillions of errors, in particular when modifying the graveyard ports). > And if we can implement a workaround, why can’t we share it with this other > page? Because I don't want to implement "build is both working and broken at the same time" functionality in buildbot. > Why would we have different pages reporting the same information? It's not exactly the same. We are already reporting that "your" ports are broken, in both buildbot and on the GitHub interface (when you browse the commits). It's just that finding a particular port in the buildbot is currently almost a mission impossible, so as a consequence nobody knows which ports are broken and which ones work, except if you check your own commits immediately a few hours after doing the commit, or read the archives of build failures sent by buildbot. The improvements on the buildbot site are meant to make the buildbot's interface itself useful (which it currently isn't, except for checking the last few builds), while the standalone app would provide a plethora of other information (installation statistics, which ports are outdated, which ones are broken, which websites are broken, ...), just collected on one single place. > > My argument is that we need to fix ports and base to avoid those > > failures, not to explain them away. > > I don’t disagree. I guess I’m not as optimistic that this will be done > quickly. It needs someone to push for a fix, someone to come up with a decend idea for the fix, and someone to actually implement it (it could be the same person). If you take the first two tasks on you, even if you don't know how to code in the base yourself, there's a high chance that you'll get help with the last part. If nobody is pushing nor suggesting what to do, this will likely not be done as fast. I'm just arguing that if we get a student working on the web app, I would prefer if he or she would perhaps spend time adding novel functionality, which could even be allowing user comments on each port (which you could use to explain why the port appears to be broken) rather than on something that should be fixed elsewhere. (I wouldn't mind the student spending time fixing that particular bug in buildbot configuration or in base if comfortable with the code, but I would definitely not want to demand from the student to fix this issue as part of the project. I'm pretty sure that we'll have plenty more serious problems that nobody is even aware of yet. And if it would be easy to fix in the web app, we'll gladly accept any patches.) Mojca
Re: Dependencies on non-default variants (was: GSoC 2019 [Collect build statistics])
> On Mar 24, 2019, at 4:05 PM, Mojca Miklavec wrote: > > On Sun, 24 Mar 2019 at 19:55, Craig Treleaven wrote: >>> On Mar 24, 2019, at 1:09 PM, Mojca Miklavec wrote: >>> On Sun, 24 Mar 2019 at 01:06, Craig Treleaven wrote: There are a number of ports that require a dependency to be installed with a non-default variant in order to build successfully. A short-coming of MacPorts is that this cannot be done progammatically When this is rolled out, we don’t want to make users think that a port will fail to build on their system when it is just a case of needing a non-default variant. However, I don’t know how to handle this cleanly. Perhaps we could parse the build log looking for the message that informs the user how to install the required variant. If found, instead of saying the build failed, we could indicate that the build was not attempted as the buildbot configuration could not support a successful install. >>> >>> I totally agree with your request, but this is completely out of scope >>> of the proposed app. This either needs a proper extension in the base, >>> or a workaround in mpbb, preferably the former. I believe a much >>> bigger general issue is reporting failure of port builds on OSes which >>> are know not to be supported (like: attempting to build the latest Qt >>> on 10.5). Again, this needs to be addressed elsewhere. >>> >> This issue hits very close to home for me. None of my MythTV ports, nor the >> hdhomerun-gui port, will build successfully on the buildbots. They never >> have. They *will* build successfully (on supported OS versions) if the >> proper variants are specified. >> >> If an unknowing potential user came to page for any of these ports and found >> nothing but failure messages for all of the buildbots, why on earth would >> they want to proceed to install the port? > > […] >> If we won’t expand the scope to handle this relatively common issue, we >> should at very least add some static text to the web page explaining that >> buildbot failures don’t mean necessarily mean the port will fail for a >> particular user. Even so, that is a very poor workaround. > > You could equally argue that users will see that ports don't fail, but > then they are buffled when they cannot install those ports on their > own machine. We should really really fix the situation in MacPorts. > Not the same at all. Now, if a user doesn’t specify the right variants they get a message that tells them what to do. Of course it would be better if that didn’t happen but this is the way things work, now. > I would say: Don't kill the messenger. Just because one application > exposes some issues with MacPorts, it doesn't mean that the > application needs to be endlessly tweaked to hide those problems away. > We should no have failing builds on the buildbot, end of story. We > need to do everything to avoid failing builds, not to implement > explanations and workarounds on the wrong level. Note that we'll > probably have another student apply for a different project which > would, if selected, expose the exact same problem on a different page. > Should we implement those workarounds ten times? > As you said, people have looked at this problem and not found a workable solution. It may be a _long_ time before a “proper” solution is implemented. In the meantime, reporting these as failed builds *actively misinforms* users. When you say there will be the same problem “on a different page”, I don’t know what you mean. And if we can implement a workaround, why can’t we share it with this other page? Why would we have different pages reporting the same information? As I see it, all we have to do is search the appropriate log for the message that the active_variants PortGroup spits out when it detects a dep with the wrong variants. If found, we replace the text “Failed” with something like “Build not attempted”. And probably add a link to a page that explains why not. Clean and elegant? No. Hard to do? Again, no. > My argument is that we need to fix ports and base to avoid those > failures, not to explain them away. I don’t disagree. I guess I’m not as optimistic that this will be done quickly. Craig
Dependencies on non-default variants (was: GSoC 2019 [Collect build statistics])
On Sun, 24 Mar 2019 at 19:55, Craig Treleaven wrote:
> > On Mar 24, 2019, at 1:09 PM, Mojca Miklavec wrote:
> > On Sun, 24 Mar 2019 at 01:06, Craig Treleaven wrote:
>>>
>>> There are a number of ports that require a dependency to be installed with
>>> a non-default variant in order to build successfully. A short-coming of
>>> MacPorts is that this cannot be done progammatically
>>>
>>> When this is rolled out, we don’t want to make users think that a port will
>>> fail to build on their system when it is just a case of needing a
>>> non-default variant.
>>>
>>> However, I don’t know how to handle this cleanly. Perhaps we could parse
>>> the build log looking for the message that informs the user how to install
>>> the required variant. If found, instead of saying the build failed, we
>>> could indicate that the build was not attempted as the buildbot
>>> configuration could not support a successful install.
>>
>> I totally agree with your request, but this is completely out of scope
>> of the proposed app. This either needs a proper extension in the base,
>> or a workaround in mpbb, preferably the former. I believe a much
>> bigger general issue is reporting failure of port builds on OSes which
>> are know not to be supported (like: attempting to build the latest Qt
>> on 10.5). Again, this needs to be addressed elsewhere.
>>
> This issue hits very close to home for me. None of my MythTV ports, nor the
> hdhomerun-gui port, will build successfully on the buildbots. They never
> have. They *will* build successfully (on supported OS versions) if the
> proper variants are specified.
>
> If an unknowing potential user came to page for any of these ports and found
> nothing but failure messages for all of the buildbots, why on earth would
> they want to proceed to install the port?
Please note that HomeBrew dropped *ALL* variants from *ALL* of their
maintained packages, saying something like: "We may discuss which
features will be turned on, or which library will be linked, but we
won't discuss adding back any of those options."
I now checked the first two random MythTV ports, which basically boils down to:
require_active_variants qt5-mysql-plugin mariadb55
require_active_variants p${perl5.major}-dbd-mysql mariadb
require_active_variants ${pymodver}-mysql mariadb55
out of which only the second one provides the wrong default variant,
and that port doesn't have the maintainer. Neither do any of the mysql
packages have any maintainer at the moment.
My first question is: why exactly does p5-dbd-mysql need a different
default variant?
My second question / suggestion: please try to take over maintenance
of the packages that you depend on and turn them into a shape that
will make them more generally usable.
> If we won’t expand the scope to handle this relatively common issue, we
> should at very least add some static text to the web page explaining that
> buildbot failures don’t mean necessarily mean the port will fail for a
> particular user. Even so, that is a very poor workaround.
You could equally argue that users will see that ports don't fail, but
then they are buffled when they cannot install those ports on their
own machine. We should really really fix the situation in MacPorts.
I would say: Don't kill the messenger. Just because one application
exposes some issues with MacPorts, it doesn't mean that the
application needs to be endlessly tweaked to hide those problems away.
We should no have failing builds on the buildbot, end of story. We
need to do everything to avoid failing builds, not to implement
explanations and workarounds on the wrong level. Note that we'll
probably have another student apply for a different project which
would, if selected, expose the exact same problem on a different page.
Should we implement those workarounds ten times?
My argument is that we need to fix ports and base to avoid those
failures, not to explain them away.
> I’m not familiar with the 2015 work.
It was about using a library to resolve dependencies in a
"mathematically correct way". If this was finished, "port install foo"
would automatically install the dependencies with the correct variant,
among others.
> ‘port’ now returns zero for successful completion. Have we considered having
> port set a return code that indicates the general class of an unsuccessful
> operation?
I'm not aware of that, but that discussion would call for a different
ticket or different topic on this mailing list.
Mojca
