On 07/06/15 at 06:17pm, Allan McRae wrote:
On 06/07/15 12:30, Andrew Gregory wrote:
On 07/06/15 at 11:35am, Allan McRae wrote:
On 05/07/15 22:44, Daniel Schoepe wrote:
On Sun, 05 Jul 2015 14:01 +0200, Allan McRae wrote:
- As discussed when I brought this up a while back, only equality constraints are supported, since the other types of bounds would have unclear semantics.
Can you clarify what is unclear there? At first glance I would think that "IgnorePkg foo < 5.0" would be useful.
You're right, this sounds like a useful constraint as well. Not sure if something like "foo > 5.0" would also have some use cases, but allowing it won't hurt, I suppose.
On the implementation side, this makes things a bit more tricky, since the code in sync.c also checks if the locally installed version is matched by IgnorePkg / IgnoreGroup. For example, when having foo-1.0 installed and setting IgnorePkg foo<1.1, an update to foo-1.2 will be ignored, since the locally installed version matches foo<1.1.
I'm not sure what the motivation is for taking the locally installed version into account. It might be sufficient to only check the package that's about to be installed.
I have no idea why the locally installed package is taken into account. That is unexpected... I agree that only checking the package that is about to be installed is the way to go.
Both the installed and incoming packages need to be checked. Otherwise replacers would be able to "upgrade" ignored packages because their names would not likely match the IgnorePkg setting.
Ohhh...
That seems an odd workaround. Can't it be done when looking at the replacement?
I think checking the incoming package is actually the odd workaround here. The reason adding a version constraint to IgnorePkg isn't straightforward is that we're trying to have IgnorePkg do two separate things. Its intended purpose, at least according to the documentation, is to pin an installed package to its current version, in which case IgnorePkg should really refer to the name of the installed package, not the incoming one. This patch is trying to turn it into a blacklist to prevent certain packages from being installed. There's obviously a lot of overlap between those two functions, but version constraints don't really make sense in the former, hence the confusion. I'm fine with having IgnorePkg do both if we can do it sanely, but I think the desired effect would be much more straightforward to achieve with a separate blacklist option. apg