On Wed, Jul 22, 2015 at 7:40 AM, Laurent Bercot <ska-supervision_at_skarnet.org
> wrote:
> On 22/07/2015 15:45, Steve Litt wrote:
>
>> http://www.troubleshooters.com/linux/politics_of_dependencies.htm
>>
>
> Yes, I had already read that, and agree with all your statements.
<snip>
>
> IMHO two years is way too stringent a requirement.
>>
>
> For a run-time dependency, or a build-time dependency on an
> external library that may itself depend on other stuff and make you
> pull the whole plate of spaghetti, yes, yes it is.
>
I'm not certain that the number of transitive dependencies actually affects
the result of the argument.
Anyhow, I hadn't considered (or known, really) that make doesn't have any
depdencies.
Possibly building it as part of my s6 build is reasonable.
>
> Distributions have a "security updates" feature, so they ARE able to
> provide software updates more often than churning out a full release
> once every three years. There's no reason why they can't use the same
> mechanism for major updates to widely used software.
There's actually a reason, and I find it compelling. Compatibility is
important.
If I package something for distroX versionY and release it to the world,
it's essentially an assurance that this package will work for you if you're
using (X,Y).
This means that backward and forward compatibility are both important.
If I've built it on an ancient, unpatched X,Y, it should still work if
yours is fully patched.
This implies that any changes which break backward compatibility cant be
accepted into X,Y, they need to go into X,Y+1.
Similarly, if I built the package on a 100% patched machine, it should
still work on your 0% patched.
This implies that changes which break *forward* compatibility can't be
accepted.
Breaking forward compatibility is commonly known as "adding features".
If I've used a recently-added feature in my package, it won't work on your
machine if you're out of date.
So feature additions also must go into n+1.
But that only holds for runtime dependencies, maybe.
For strictly build-time dependencies, maybe it's fine that the
package-consumer couldn't have rebuilt
the package with her installation, as long as they can depend on it running.
It seems like a bleak situation though.
Received on Wed Jul 29 2015 - 20:00:14 UTC