{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/arcade/issues/1677","repository_url":"https://api.github.com/repos/dotnet/arcade","labels_url":"https://api.github.com/repos/dotnet/arcade/issues/1677/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/arcade/issues/1677/comments","events_url":"https://api.github.com/repos/dotnet/arcade/issues/1677/events","html_url":"https://github.com/dotnet/arcade/issues/1677","id":395424825,"node_id":"MDU6SXNzdWUzOTU0MjQ4MjU=","number":1677,"title":"Diamond dependencies and darc","user":{"login":"natemcmaster","id":2696087,"node_id":"MDQ6VXNlcjI2OTYwODc=","avatar_url":"https://avatars0.githubusercontent.com/u/2696087?v=4","gravatar_id":"","url":"https://api.github.com/users/natemcmaster","html_url":"https://github.com/natemcmaster","followers_url":"https://api.github.com/users/natemcmaster/followers","following_url":"https://api.github.com/users/natemcmaster/following{/other_user}","gists_url":"https://api.github.com/users/natemcmaster/gists{/gist_id}","starred_url":"https://api.github.com/users/natemcmaster/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/natemcmaster/subscriptions","organizations_url":"https://api.github.com/users/natemcmaster/orgs","repos_url":"https://api.github.com/users/natemcmaster/repos","events_url":"https://api.github.com/users/natemcmaster/events{/privacy}","received_events_url":"https://api.github.com/users/natemcmaster/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2019-01-03T00:33:48Z","updated_at":"2019-01-03T15:39:09Z","closed_at":null,"author_association":"MEMBER","body":"Some of our repos have diamond dependencies. Dependency updates via darc attempt to solve this problem by always updating repos to use the latest versions of dependencies on a channel. This is not always the correct solution for how diamond dependencies should be resolved. How can repos describe additional constraints on dependency updates to ensure darc updates are correct?\r\n\r\n**Scenario**: AspNetCore, core-setup, and corefx\r\n\r\nThe aspnet/AspNetCore repo has a dependency on System.Reflection.Metadata (from dotnet/corefx) and Microsoft.NETCore.App (dotnet/core-setup), and dotnet/core-setup has a dependency on System.Reflection.Metadata (corefx). \r\n```\r\n     ---------> core-setup ---------\r\n     |                             |\r\n     |                             v\r\n corefx ----------------------> aspnetcore\r\n```\r\n\r\nThe version of System.Reflection.Metadata used by AspNetCore must be less than or equal to the version that was used in Microsoft.NETCore.App.\r\n\r\n**Problem**: let's say the latest packages on the dev channel are corefx 3.0.0.1 and core-setup 3.0.0.1. Corefx produces a new build, 3.0.0.2. If maestro creates an update PR **before** core-setup has re-built using corefx 3.0.0.2, the update to AspNetCore would be invalid:\r\n\r\n    Wrong:\r\n    aspnetcore -> Microsoft.NetCore.App 3.0.0.1 -> System.Reflection.Metadata 3.0.0.1\r\n    aspnetcore -> System.Reflection.Metadata  3.0.0.2\r\n\r\n    Correct, but not available yet:\r\n    aspnetcore -> Microsoft.NetCore.App (TBD) -> System.Reflection.Metadata 3.0.0.2\r\n    aspnetcore -> System.Reflection.Metadata  3.0.0.2\r\n\r\n\r\nThe update should wait until core-setup has been re-built using corefx 3.0.0.2. \r\n\r\nFortunately, AspNetCore has PR checks which would fail, so it wouldn't be merged, but how do we prevent this from happening in the first place?\r\n\r\ncc @mmitche \r\n"},"comment":{"url":"https://api.github.com/repos/dotnet/arcade/issues/comments/451180577","html_url":"https://github.com/dotnet/arcade/issues/1677#issuecomment-451180577","issue_url":"https://api.github.com/repos/dotnet/arcade/issues/1677","id":451180577,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MTE4MDU3Nw==","user":{"login":"mmitche","id":8725170,"node_id":"MDQ6VXNlcjg3MjUxNzA=","avatar_url":"https://avatars1.githubusercontent.com/u/8725170?v=4","gravatar_id":"","url":"https://api.github.com/users/mmitche","html_url":"https://github.com/mmitche","followers_url":"https://api.github.com/users/mmitche/followers","following_url":"https://api.github.com/users/mmitche/following{/other_user}","gists_url":"https://api.github.com/users/mmitche/gists{/gist_id}","starred_url":"https://api.github.com/users/mmitche/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mmitche/subscriptions","organizations_url":"https://api.github.com/users/mmitche/orgs","repos_url":"https://api.github.com/users/mmitche/repos","events_url":"https://api.github.com/users/mmitche/events{/privacy}","received_events_url":"https://api.github.com/users/mmitche/received_events","type":"User","site_admin":false},"created_at":"2019-01-03T15:39:09Z","updated_at":"2019-01-03T15:39:09Z","author_association":"MEMBER","body":"I've been thinking about this and don't have a good solution yet.  There are some other interesting details though:\r\n- There's not necessarily a direct dependency chain.  For example, core-setup depends directly on corefx's\r\n  - Microsoft.Private.CoreFx.NETCoreApp\r\n  - Microsoft.NETCore.Platforms\r\n\r\n  But nothing else. However, aspnet depends on Microsoft.NetCore.App as well as a host of other corefx binaries.  So in fact, we're really saying that you can't upgrade a particular corefx binary unless the *build* it came from was also pulled into core-setup, specifically that build's Microsoft.Private.CoreFx.NETCoreApp and Microsoft.NETCore.Platforms bits. This means that there are implicit relationships between Microsoft.Private.CoreFx.NETCoreApp and other corefx outputs that aren't actually encoded in the inputs to the core-setup build.\r\n  This feels a bit like a product issue that we're going to have to paper over with the dependency system.\r\n- You could have other cases where binaries produced in a build are in fact truly independent, so you can't just blanket make a rule where all binaries in a build must move as a unit.\r\n\r\nMaybe the what needs to be done is that we make core-setup's inputs reflective of the actual dependency structure, then add a way to specify in the version.details.xml that a group of binaries must have familial relationships.\r\n\r\nI'll need to think on it some more."}}
{"actor":{"display_login":"mmitche"}}