{"action":"created","issue":{"url":"https://api.github.com/repos/archzfs/archzfs/issues/273","repository_url":"https://api.github.com/repos/archzfs/archzfs","labels_url":"https://api.github.com/repos/archzfs/archzfs/issues/273/labels{/name}","comments_url":"https://api.github.com/repos/archzfs/archzfs/issues/273/comments","events_url":"https://api.github.com/repos/archzfs/archzfs/issues/273/events","html_url":"https://github.com/archzfs/archzfs/issues/273","id":377622105,"node_id":"MDU6SXNzdWUzNzc2MjIxMDU=","number":273,"title":"Confusing and useless zfs-utils-common, spl-utils-common packages","user":{"login":"eli-schwartz","id":6551424,"node_id":"MDQ6VXNlcjY1NTE0MjQ=","avatar_url":"https://avatars1.githubusercontent.com/u/6551424?v=4","gravatar_id":"","url":"https://api.github.com/users/eli-schwartz","html_url":"https://github.com/eli-schwartz","followers_url":"https://api.github.com/users/eli-schwartz/followers","following_url":"https://api.github.com/users/eli-schwartz/following{/other_user}","gists_url":"https://api.github.com/users/eli-schwartz/gists{/gist_id}","starred_url":"https://api.github.com/users/eli-schwartz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eli-schwartz/subscriptions","organizations_url":"https://api.github.com/users/eli-schwartz/orgs","repos_url":"https://api.github.com/users/eli-schwartz/repos","events_url":"https://api.github.com/users/eli-schwartz/events{/privacy}","received_events_url":"https://api.github.com/users/eli-schwartz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-11-05T23:08:09Z","updated_at":"2018-11-06T18:22:13Z","closed_at":null,"author_association":"NONE","body":"As far as I can tell, these were created solely because the existing zfs-utils and spl-utils packages were split packages that caused people to build the dkms packages (although installation was not forced).\r\n\r\nThere's no reason they should exist, to be honest, and since taking over the dkms packages I have split out zfs-utils into a separate PKGBUILD. So all the existing zfs packages should start using a unified package name that everyone can agree upon...\r\n\r\nSide note: spl-utils is useless and only contains testsuite binaries, there's zero reason to force people to install it IMO. But if you really want it, please rename spl-utils-common to spl-utils, because there is nothing \"-common\" about just-a-dependency.\r\n\r\nAlso: https://lists.archlinux.org/pipermail/aur-requests/2018-November/027729.html"},"comment":{"url":"https://api.github.com/repos/archzfs/archzfs/issues/comments/436355706","html_url":"https://github.com/archzfs/archzfs/issues/273#issuecomment-436355706","issue_url":"https://api.github.com/repos/archzfs/archzfs/issues/273","id":436355706,"node_id":"MDEyOklzc3VlQ29tbWVudDQzNjM1NTcwNg==","user":{"login":"eli-schwartz","id":6551424,"node_id":"MDQ6VXNlcjY1NTE0MjQ=","avatar_url":"https://avatars1.githubusercontent.com/u/6551424?v=4","gravatar_id":"","url":"https://api.github.com/users/eli-schwartz","html_url":"https://github.com/eli-schwartz","followers_url":"https://api.github.com/users/eli-schwartz/followers","following_url":"https://api.github.com/users/eli-schwartz/following{/other_user}","gists_url":"https://api.github.com/users/eli-schwartz/gists{/gist_id}","starred_url":"https://api.github.com/users/eli-schwartz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eli-schwartz/subscriptions","organizations_url":"https://api.github.com/users/eli-schwartz/orgs","repos_url":"https://api.github.com/users/eli-schwartz/repos","events_url":"https://api.github.com/users/eli-schwartz/events{/privacy}","received_events_url":"https://api.github.com/users/eli-schwartz/received_events","type":"User","site_admin":false},"created_at":"2018-11-06T18:22:13Z","updated_at":"2018-11-06T18:22:13Z","author_association":"NONE","body":"> The reason behind the common packages was exactly like you said: zfs-utils did already exist and wasn't a split package.\r\n\r\nTechnically speaking, this isn't really a good reason for creating a duplicate. The package can still be built and installed either way.\r\n\r\n> Another reason is that we don't have control over the utils package and because of that, our version in the repo is never the same package as the one in the aur. if we change the init hook or update / patch zfs, zfs-utils might still be outdated for aur users and they wouldn't be able to update easily or have a different experience than repo users.\r\n\r\nThis is also not a reason. There are many packages in all of Arch Linux, which depend on each other despite being maintained by different people. If one package doesn't get \"patched\", then the appropriate response is usually not to fork the package, but rather, to discuss with the maintainer of the package why it should be patched.\r\n\r\nAnyways I do not understand how this would prevent users from updating. If the package is simply not getting updated, sure... but you can use versioned depends for this, and cause the update to be held until the dependency is updated. This would maybe encourage unresponsive maintainers to be responsive, encourage users to be responsive about flagging packages out of date or submitting orphan requests, and in general encourage everyone to work together, which is purportedly a goal of the AUR.\r\n\r\nThat being said, I'm pretty well active and don't anticipate lagging in this package, sooooo... shouldn't be a problem in future.\r\n\r\n> I think the best solution to this would be, to hook up the zfs-dkms and zfs-utils package to our buildsystem to update everything at once and have one codebase for all zfs packages.\r\n\r\nI'm intimidated by meta-build systems which, to me, obscure the actual resources being used, introduce heavily layered assumptions, and make it difficult to figure out where to update what is, in the end, actually a very simple build recipe.\r\n\r\n> Another option would be to have archzfs your zfs-dkms aur package completely separated. To avoid confusion, we could rename the zfs-utils-common package to something like zfs-utils-archzfs.\r\n\r\nThat would reduce confusion, but it would not reduce duplication, which I think to be a valid additional concern.\r\n\r\n...\r\n\r\nLet's consider the case where zfs-utils is not being updated because the maintainer is slow. Assuming the zfs-linux package is updated and requires in turn an updated zfs-utils, the pinned dependency would result in the package simply being uninstallable from the AUR, period.\r\n\r\nThe result would be that users of the AUR get told \"please ask the zfs-utils maintainer to provide an update, alternatively you can use the PKGBUILD from the github repo at XXXXX, or use our prebuilt repository\". This doesn't seem very ideal, but it would put the responsibility where it belonged. I'd actually opt, instead, for providing updates in the custom repo but not deploying that to the AUR -- then telling users via a pinned comment that the update is waiting for a dependency to be updated, \"please consider using our custom repo in the meantime\". :D"}}
{"actor":{"display_login":"eli-schwartz"}}