Subject: Re: Outdated ion3 pkgsrc in violation of the license
To: matthew sporleder <firstname.lastname@example.org>
From: David Maxwell <email@example.com>
Date: 10/29/2007 10:36:47
On Mon, Oct 29, 2007 at 10:51:44AM -0400, matthew sporleder wrote:
> On 10/29/07, Tuomo Valkonen <firstname.lastname@example.org> wrote:
> > There needs to be package systems, but decentralised ones that authors
> > can easily use to provide their software in for various platforms, and
> > not have to fall victim to centralised (megafreeze) distributions that
> > couldn't give a rat's ass about the author's time, reputation, and vision
> > for the project.
That statement could easily be inverted, and be just as valid....
"package authors that don't care about an OS (or packaging system)
authors' time, reputation, and vision for the project."
An issue is that both the package's authors and the OS's authors feel
like the user 'belongs to them'.
The package authors want users to have the latest and greatest version,
because the end-user is missing out (or vulnerable) if they're on an
older version. The package authors also don't want to be burdened with
support requests for old software, whose issues may already be addressed
in a newer release.
The OS authors don't want to be burdened with requests for fixes to
dependency issues by users who just want to _use_ the system and the
package, not _develop_ them.
The anti-megafreeze dogma starts with the implicit assumption that all
users absolutely want to be running the absolute latest code all the
time. That's simply not true. Developers want that, but users do not.
pkgsrc offers a reasonable tradeoff. One wants the cutting-edge package
versions, one runs pkgsrc-current. One wants a stable set of packages,
still protected against vulnerabilities by audit-packages, one runs a
I happen to agree with some of the previous comments, that 28 day update
requirements are an unreasonable demand in a volunteer environment, but
I think that only hurts uptake of the package in question. Packaging
systems won't bother to include it, because the barrier is set too high,
so fewer users will encounter it. Those who care can hand-build it.
If a pkgsrc developer cares enough about this particular package, the
license provides options to make it work - renaming, or clearly
displaying a message.
As soon as a solution to both parties' needs exists, (reliable builds
from -current, or any release of any package) this will become a
David Maxwell, email@example.comfirstname.lastname@example.org -->
Any sufficiently advanced Common Sense will seem like magic...