package, package2, package3 naming-with-version exploit

Richard W.M. Jones rjones at redhat.com
Wed Apr 3 19:00:56 UTC 2013


On Wed, Apr 03, 2013 at 08:39:38PM +0200, Nicolas Mailhot wrote:
> And that is just a rehash of the old "it's too much work to help the
> upstreams of my deps to fix their stuff, I'll workaround it locally"
> argument.
> 
> That way of working does not scale. It's just a developer shortcut to
> avoid paying his technical debts and push the problems to someone else
> downstream.
> (note that those developer problems are always caused by other developer
> sloppy practices but they blame the distro environment that forces them to
> do something about it). Besides, it is against Fedora's explicit goals.
> 
> The root of the clashes between devs and system/distro people is that devs
> are used to having layers of people they can dump un-sexy problems on (qa,
> systems, support) while distro people tend to be more aware the next layer
> is the user and system success is about not dumping problems on them.

I agree with everything you say and think you're completely right
about this, nevertheless here's a devil's advocate argument ...

Several upstream communities have terrible development practices and
are very resistant to change.  That in itself wouldn't matter, but
these same development communities also make software which is very
popular.

Distros that embrace and work with this software are going to be much
more popular than those that don't, because at the end of the day the
purpose of having an operating system is to run applications.

So we have, I think, four choices:

(1) embrace the software, allow it to be shipped (or even ship it
ourselves), and don't care about the security problems

(2) deal with the combinatorial security explosion of having multiple
parallel versions of badly engineered packages installed, requiring
loads of extra manpower (from where?!)

(3) spend ages educating the upstream developers on best practices,
and patching and fixing upstream software ourselves

(4) don't embrace or ship this software, and risk obscurity

I think #3 or #4 is where we are right now.

None of this means we have to make odd changes to RPM however, since
RPM can quite happily deal with the packaging problems already or at
least with very minor enhancements.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW


More information about the devel mailing list