Alan McKinnon <alan.mckin...@gmail.com> wrote: > > It seems to me that you didn't read the whole post fully, and have > cherry-picked a part that you think bolsters your position.
I do not think that I have a position here. Subslots solve some problem. If they cause inconveniences like portage needing too long or frequent reemerges, these issues should be attacked separately. > I've run emerge -e world with the result of correcting something perhaps > 2 or 3 times in 8 years. You *realized* the necessity 2-3 times in 8 years. For a production system one usually does not want an unrecognized breakage ever. > In effect subslots appear to fix something for me about once a year. Given that on a production system you would have something seriously broken once a year which is not the case with subslots, I would say they have reached their goal. > So now we have a rather large complex system It is not complex at all: Except taking the dependency string directly from the metadata it is before modified with information from /var/db, and during merging the corresponding information is stored in /var/db. Nothing magic is going on. I think there is mainly a perception problem: Whenever there is a problem with dependencies now subslots are blamed, because they are shown by portage first. In my experience, all these problems were just "usual" dependency problems which just happen from to time and will always happen - not related with subslots at all. > Consider for a moment the maintenance burden imposed on ebuild > maintainers If your package provides a library and you bump the version you also bump the subslot except if you happen to know for sure that the library remains ABI-compatible. If you are short on time this is a matter of seconds, if you are more careful and want to do an excellent work you can remember upstream's policy to save the user from an unnecessary rebuild. > and how sub-slot notation is essentially added by humans > deploying human brains. And remember that humans are notoriously bad at > using mathematically correct solutions (they ... err ... forget to do > stuff). Yes, somebody might make a mistake and forget to bump or do an unnecessary bump. So what? All sort of mistakes can happen everywhere which can lead to all sort of problems. > I predict once a week fallout from sub-slots induced bugs that was > intended to fix once a year problem. Let's see: Forgetting to bump a subslot means that the purpose of subslots for that package fails. A problem, but not worse than without subslots. Bumping unnecessarily means that perhaps some packages are rebuilt unnecessarily. Also not something dramatic. Even if this *should* happen once a week (which I strongly doubt; more realistic is once in a few months) nothing dramatic happens.
