| 1 |
On Mon, 2 May 2011 14:34:11 +0200 |
| 2 |
Maciej Mrozowski <reavertm@×××××.com> wrote: |
| 3 |
> And wrt blocks it would still work. It's not like clarifying |
| 4 |
> self-mutual blocks semantics would magically alter behaviour with |
| 5 |
> regards to how the package is merged. It may only have consequences |
| 6 |
> on package set level, not ebuild level. |
| 7 |
|
| 8 |
You can't split the two concepts up. Whether or not a package builds is |
| 9 |
affected by what is or isn't installed. |
| 10 |
|
| 11 |
> But then again, IIRC Paludis still doesn't perform auto- unmerging of |
| 12 |
> not referenced soft-blocked packages and it's being extensively used |
| 13 |
> in gentoo-x86 tree and I see nobody screaming... (this may have |
| 14 |
> changed however, my point is invalid if that's the case) |
| 15 |
|
| 16 |
Paludis won't uninstall things without explicit permission. It will, |
| 17 |
however, tell the user that something is blocked, and give the user the |
| 18 |
option of saying "yes, uninstall that". This is deliberate, to avoid |
| 19 |
the situations we've had with Portage uninstalling bash. |
| 20 |
|
| 21 |
Also note that Paludis treats pre-EAPI 2 ! blocks as being strong, not |
| 22 |
weak. Again, deliberate, because that's what authors of pre-EAPI 2 |
| 23 |
ebuilds originally intended. |
| 24 |
|
| 25 |
> The problem is that person most interested in participating in such |
| 26 |
> discussion, the one solely responsible for reference and supported |
| 27 |
> package manager implementation (for Gentoo) is Zac, but he's not |
| 28 |
> interested in (or doesn't have time for) bickering with Ciaran (who |
| 29 |
> apparently does have time) and I don't blame him at all frankly (I |
| 30 |
> don't blame Ciaran either, he could just try to avoid stating his |
| 31 |
> opinion on how broken Portage is on every single occasion he has like |
| 32 |
> anyone even cared.. and send patches instead). |
| 33 |
|
| 34 |
What I have time for is making sure we get this right at the |
| 35 |
specification level. Mistakes in the specification cost a lot more in |
| 36 |
the long term than careful consideration of consequences does in the |
| 37 |
short term. The last time blockers were changed without careful |
| 38 |
thought, lots of things broke horribly, and we're still hitting obscure |
| 39 |
breakages years later. |
| 40 |
|
| 41 |
As for sending patches, you said it yourself: |
| 42 |
|
| 43 |
> Well, just look at portage - only few are brave enough to |
| 44 |
> touch it and even fewer know how it really works. |
| 45 |
|
| 46 |
So I've done something better: I've made an alternative that doesn't |
| 47 |
have those problems. |
| 48 |
|
| 49 |
> Anyway Ciaran diverged discussion to what's the purpose of EAPI and |
| 50 |
> what's not. Not sure what's the time line for "in the old days |
| 51 |
> Portage treated all blockers as being a bit like what strong blockers |
| 52 |
> are now" is |
| 53 |
|
| 54 |
It's after EAPI 0, thus, we control changes to it using EAPIs. Simple! |
| 55 |
|
| 56 |
Again, getting this right *matters*. Regarding the original bug that |
| 57 |
brought our attention to this, I believe the first part of the problem |
| 58 |
there is that some cron packages are using pre-2 EAPIs, which means |
| 59 |
their ! blockers are treated by recent Portage versions as weak (and |
| 60 |
old Portage versions as strong) but by Paludis as strong. |
| 61 |
|
| 62 |
-- |
| 63 |
Ciaran McCreesh |
Archives