Re: Arguments for basing upon Debian
On 2011-10-08 1:19 PM, Jeremiah C. Foster wrote:
> Note that there already is an entry in the Debian Derivatives Census
> that you are welcome to improve if you're interested;
> Ignore those. They are largely not germane or technically grounded in
> the facts.
I guess that's the only way. It's difficult to ignore nonsense being
peddled repeatedly in some variety of feedback loop though, more so when
it's something you care about. I guess I'm just hoping to spur the
brighter individuals to investigate things for themselves once they
realise these incorrect statements aren't axioms.
> These are all debatable, and in some ways, unprovable positions. That
> one packaging format is "better" than another due to some technical
> capacity is specious. That yum is better than apt is factually
> incorrect. Solving dependency resolution is, and has been for years,
> much better in APT than in yum and in rpm in general. Zypper has made
> significant improvements in that area however so the rpm platform is
> largely similar to ATP now, but yum is still inferior on its own. I
> find it risible to imply that a directory layout is more suitable for
> mobile computing. How would one even make that argument? Red Hat, a
> very large commercial company, had a great deal of sway when it came
> time to pick a packaging format when the Linux Standards Base was
> formed. This is unfortunate in some ways since the decision was taken
> on a commercial and not a technical basis, but it is fortunate that
> Debian has excellent support for rpms as a consequence. There is also
> work (SPDX I believe) being done to ameliorate much of the differences
> between the two formats.
I will confess that the transactions support that the higher-level
Redhat tools were mentioned to feature does sound to have merit. It's
good to hear about SPDX. I'd so love these pointless them and us
discussions to go away. I've no problem moving to a better
toolchain...but a different one for difference sake is just a waste of
my time. :)
The details of some of the points made were more along the lines that
Debian's dependency resolution apparently requires the full dataset to
be available and parsed, and scanning millions of packages for
dependencies would strain a limited-resource mobile device. To help make
their case they pointed out that an apt-get update downloaded 13MB and
took 13 seconds. I pointed out the same on my Debian server only
required 273KB in 11 seconds...which forced them to admit they'd cleared
their cache first. ;)
Another referred to signing the package file rather than individual DEBs
as a security issue due to MitM attacks? I don't know enough to comment.
> This is not the path to choose, though it may seem the right one. I've
> gone down this specific path. I was the maemo debmaster and I brought
> the request to support debs in front of MeeGo's TSG. No amount of
> rational argument was persuasive. I don't see how this would change
> now as I know all the principle actors in Mer, Maemo, MeeGo (I'm the
> Release Manager for MeeGo IVI), and I hope to be involved in Tizen as
> well as increase my work in Debian.
You sound like a useful person to know, and thank you for your attempts.
> One must understand the choice of rpm vs. deb is made on two levels -
> the individual level and the commercial level.
> This is why the debate is so infected with FUD.
That's an interesting bit of insight. I'd kinda assumed that the choice
would be a bit more technical. Whichever base suited their purposes more
would be chosen and that would bind them to the infrastructure.
> Here's the best path forward; - Write great software - License it
> under a strong copyleft license - Contribute to truly open projects
> That's it. Based on those criteria one might propose that a Debian
> based re-spin of Mer (let's call it DeMer) might be a good path
> forward if you wanted a new project to work on. If not, you can
> participate in a number of good projects, like GNU, Fedora or Debian.
> My choice is Debian, because of its social contract, its high quality
> software, its support for a number of architectures, and because of
> the people involved. Your choice of course will likely be different.
> :-) Regards, Jeremiah
Indeed. My attempts to get stronger ties to Debian in these new projects
is basically because I don't have the resources to run a project like
this myself and duplicating, say, the Mer project, seems like such a
waste of resources. I'd love to be a part of a Debian Mobile project
based upon Maemo with stronger ties to Debian as Ubuntu has, but I just
don't want to be the entire project ;). I see being able to leverage the
Debian project's resources as a great way to minimise the work required
in the forked distro, if you will. I do contribute to Debian (for much
the same reasons you do, apparently) as time allows (usually bug reports
and troubleshooting, and the odd small patch)...but unfortunately that
constraint means I can probably only be a small cog in a project, and
thus somewhat reliant on those further up the project food chain.
Nokia has largely succeeded in poisoning the well (in order to garner
new device sales) by enticing the most talented community developers
away from Maemo to MeeGo (such is usually the problem with a hardware
vendor directing software devlopment), which makes building a critical
mass of development around even more difficult.