Suppose, a user wants to install a package from unstable branch or a masked package which pulls in a lot of unstable/masked dependencies, in this case, he'll have to mark each dependency in package.keywords/mask. This can be done automatically via autounmask feature, but regardless of what method we use, this'll overcrowd the text file. The solution to this is to put a single entry in the keyword/unmask file - kde-base/kdebase-meta ~~amd64 (with the double ~) And it's going to automatically unmask all packages that depend on kdebase-meta. Another major advantage is that, if, in the future, a masked/keyworded dependency is removed from the package, it'll be taken care of automatically without searching for these redundant entires manually in the keyword/unmask file; actually this's the main advantage. Reproducible: Always
Would you want it to unmask newer versions even if there's already an unmasked version to satisfy a dependency?
(In reply to comment #1) > Would you want it to unmask newer versions even if there's already an > unmasked version to satisfy a dependency? No, but, if I've manually unmasked a higher version then that higher version should be preferred instead.
(In reply to comment #0) > Suppose, a user wants to install a package from unstable branch or a masked > package which pulls in a lot of unstable/masked dependencies, in this case, > he'll have to mark each dependency in package.keywords/mask. This can be > done automatically via autounmask feature, but regardless of what method we > use, this'll overcrowd the text file. > > The solution to this is to put a single entry in the keyword/unmask file - > > kde-base/kdebase-meta ~~amd64 > > (with the double ~) > > And it's going to automatically unmask all packages that depend on > kdebase-meta. > > Another major advantage is that, if, in the future, a masked/keyworded > dependency is removed from the package, it'll be taken care of automatically > without searching for these redundant entires manually in the keyword/unmask > file; actually this's the main advantage. > Why do you care about these redundant entries at all? Leaving them where they are doesn't do any harm. And even if you care, there are tools to do that (i.e. eix-test-obsolete). A useful approach is to put all entries that are needed for a given package into a separate file. Having said that, there are several problems with your approach: * For every operation you'd have to do full dependency resolution to know what has been unmasked. * Dependency resolution for packages that aren't installed has to be done too (i.e. there is an ~~ entry for a package which is not installed) * You'd always have to use backtracking because the resolver will see config updates again and again, making it even slower. * Changing USE may put the system in an inconsistent state (i.e. ~~A unmask B-2 if USE foo is enabled for A, but if foo is disabled B-2 is not unmasked. If you change from foo to -foo B-2 will still be installed but is masked. * It would be hard to answer why some specific package has been unmasked. (i.e. there is a need for just another tool that figures this out).
(In reply to comment #3) > (In reply to comment #0) > > Suppose, a user wants to install a package from unstable branch or a masked > > package which pulls in a lot of unstable/masked dependencies, in this case, > > he'll have to mark each dependency in package.keywords/mask. This can be > > done automatically via autounmask feature, but regardless of what method we > > use, this'll overcrowd the text file. > > > > The solution to this is to put a single entry in the keyword/unmask file - > > > > kde-base/kdebase-meta ~~amd64 > > > > (with the double ~) > > > > And it's going to automatically unmask all packages that depend on > > kdebase-meta. > > > > Another major advantage is that, if, in the future, a masked/keyworded > > dependency is removed from the package, it'll be taken care of automatically > > without searching for these redundant entires manually in the keyword/unmask > > file; actually this's the main advantage. > > > > Why do you care about these redundant entries at all? Leaving them where > they are doesn't do any harm. And even if you care, there are tools to do > that (i.e. eix-test-obsolete). > A useful approach is to put all entries that are needed for a given package > into a separate file. As I already stated in the report, if, in the future, a masked/keyworded dependency is removed from the package, it'll be taken care of automatically without searching for these redundant entires manually in the keyword/unmask file; actually this's the main advantage. > > Having said that, there are several problems with your approach: > * For every operation you'd have to do full dependency resolution to know > what has been unmasked. This problem can be solved by caching the result to a location after each sync. After each sync, the keywords.* files will be expanded to plane packages, and cached. > * Dependency resolution for packages that aren't installed has to be done > too (i.e. there is an ~~ entry for a package which is not installed) > * You'd always have to use backtracking because the resolver will see config > updates again and again, making it even slower. Config updates... but that's done every time. > * Changing USE may put the system in an inconsistent state (i.e. ~~A unmask > B-2 if USE foo is enabled for A, but if foo is disabled B-2 is not unmasked. > If you change from foo to -foo B-2 will still be installed but is masked. I kind of didn't understand. > * It would be hard to answer why some specific package has been unmasked. > (i.e. there is a need for just another tool that figures this out).
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #0) > > > Suppose, a user wants to install a package from unstable branch or a masked > > > package which pulls in a lot of unstable/masked dependencies, in this case, > > > he'll have to mark each dependency in package.keywords/mask. This can be > > > done automatically via autounmask feature, but regardless of what method we > > > use, this'll overcrowd the text file. > > > > > > The solution to this is to put a single entry in the keyword/unmask file - > > > > > > kde-base/kdebase-meta ~~amd64 > > > > > > (with the double ~) > > > > > > And it's going to automatically unmask all packages that depend on > > > kdebase-meta. > > > > > > Another major advantage is that, if, in the future, a masked/keyworded > > > dependency is removed from the package, it'll be taken care of automatically > > > without searching for these redundant entires manually in the keyword/unmask > > > file; actually this's the main advantage. > > > > > > > Why do you care about these redundant entries at all? Leaving them where > > they are doesn't do any harm. And even if you care, there are tools to do > > that (i.e. eix-test-obsolete). > > A useful approach is to put all entries that are needed for a given package > > into a separate file. > > As I already stated in the report, if, in the future, a masked/keyworded > dependency is removed from the package, it'll be taken care of automatically > without searching for these redundant entires manually in the keyword/unmask > file; actually this's the main advantage. Yeah, but I don't see why removing those entries is that important. > > > > > Having said that, there are several problems with your approach: > > * For every operation you'd have to do full dependency resolution to know > > what has been unmasked. > > This problem can be solved by caching the result to a location after each > sync. You can't cache them as they depend on USE settings and p.keywords entries (and other things). > > After each sync, the keywords.* files will be expanded to plane packages, > and cached. > > > * Dependency resolution for packages that aren't installed has to be done > > too (i.e. there is an ~~ entry for a package which is not installed) > > * You'd always have to use backtracking because the resolver will see config > > updates again and again, making it even slower. > > Config updates... but that's done every time. > I'm not talking about changes like the user editing p.use. I'm talking about those changes that are performed on the fly during dependency calculations (i.e. changes produced by --autounmask). > > * Changing USE may put the system in an inconsistent state (i.e. ~~A unmask > > B-2 if USE foo is enabled for A, but if foo is disabled B-2 is not unmasked. > > If you change from foo to -foo B-2 will still be installed but is masked. > > I kind of didn't understand. A-1 has DEPEND="foo? ( >=B-2 )" B-1 has KEYWORDS="x86" B-2 has KEYWORDS="~x86" There is an ~~A entry in p.keywords If A is going to be installed with USE="foo", then B-2 needs to be keyworded. If A is going to be installed with USE="-foo", B doesn't need to be keyworded. > > > * It would be hard to answer why some specific package has been unmasked. > > (i.e. there is a need for just another tool that figures this out).
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #0) > > > > Suppose, a user wants to install a package from unstable branch or a masked > > > > package which pulls in a lot of unstable/masked dependencies, in this case, > > > > he'll have to mark each dependency in package.keywords/mask. This can be > > > > done automatically via autounmask feature, but regardless of what method we > > > > use, this'll overcrowd the text file. > > > > > > > > The solution to this is to put a single entry in the keyword/unmask file - > > > > > > > > kde-base/kdebase-meta ~~amd64 > > > > > > > > (with the double ~) > > > > > > > > And it's going to automatically unmask all packages that depend on > > > > kdebase-meta. > > > > > > > > Another major advantage is that, if, in the future, a masked/keyworded > > > > dependency is removed from the package, it'll be taken care of automatically > > > > without searching for these redundant entires manually in the keyword/unmask > > > > file; actually this's the main advantage. > > > > > > > > > > Why do you care about these redundant entries at all? Leaving them where > > > they are doesn't do any harm. And even if you care, there are tools to do > > > that (i.e. eix-test-obsolete). > > > A useful approach is to put all entries that are needed for a given package > > > into a separate file. > > > > As I already stated in the report, if, in the future, a masked/keyworded > > dependency is removed from the package, it'll be taken care of automatically > > without searching for these redundant entires manually in the keyword/unmask > > file; actually this's the main advantage. > > Yeah, but I don't see why removing those entries is that important. > When you're using the stable branch, you try and use maximum stable package. Without these entries removed, that's not going to happen. Your concerns are right, as a result, I've thought of another workaround to the above problem. There should be a tool to check the masked dependencies of the masked packages which are in the world file. For e.g. if I installed A (~amd64) manually, which pulls in dependencies as B(~amd64), C (**), then this tool should check if A still (maybe after an upgrade) depends on B(~amd64) and C(**), if not (for e.g. if A (~amd64) depends on B(amd64) which's still installed from unstable branch), then it'll point out that you may install B from the stable branch to satisfy A(~amd64), and optionally remove these entries automatically.
