On Wednesday 12 October 2011 17:42:47 Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> > otherwise, Rich summed up things nicely in his later post.
> If you mean that common sense thing: if there is disagreement about it,
> then it is obviously not common.
you're mixing "common" with "absolute". so far, you're the only one who seems
to think that this behavior is generally acceptable.
> >> The second time the package was removed was even without mask or
> >> announcement.
> > well, it shouldn't have been re-added in the first place
> Why not? Nothing in the Gentoo documentation forbids adding an ebuild
> which downgrades linux-headers or any other package.
there is plenty of stupid stuff the documentation doesn't forbid. again, refer
to Rich's post.
qutecom is hardly an important package that it gets an exception. i'm sure
all 3 Gentoo users were saddened by its demise.
> And it is not that I dumped the package to rot there. In my email to
> -devel I said that I was going to address the problem that suddenly
> became so urgent.
it doesn't matter if you intended on getting the issues fixed. the issue
shouldn't have been reintroduced in the first place. nothing in this path
necessitated adding bad packages back to the tree.
> > your package is already broken,
> > and removing the linux-headers would break that depgraph.
> The removed qutecom ebuild was not broken at any time.
by splitting my reply, you changed the meaning. having qutecom in the tree
with a depend on versions that i'm now removing breaks the depgraph.
> runs fine with the packages in portage. It may trigger a linux-headers
> downgrade, but if that really causes breakage in other packages (and I
> am not convinced, as you gave only vague arguments, and a Google search
> didn't turn up anything)
i provided a hypothetical that is not unreasonable. if google could look up
hypotheticals, then it's probably self-aware.
> then it could be reason for masking. But not reason for removal.
we don't generally keep masked things in the tree. it's broken, it gets
masked, then it gets removed. this isn't complicated.
> Only after all <linux-headers-2.6.38 versions are removed, then it is
> indeed uninstallable and needs to be fixed or treecleaned.
the existence of other versions is irrelevant. your pkg is broken and needs
to be fixed now regardless of what happens to old linux-headers versions.