[Arm-netbook] GK802 for $70

[luke.leighton]

On Sat, May 25, 2013 at 6:19 PM, Marco Caminati <spam.caminati at yahoo.com> wrote:
>> 55 pages with about 6 packages per page, that's 330 packages.
>
> Actually and currently, there are 4231 packages in the repo for the only architecture officially supported.

 ok apologies i missed those.  it's still 10 times less packages, and
10 times less architectures.

>> i've said it twice now - this makes it three times: debian manages
>> over THIRTY THOUSAND packages.  they also manage i think it's 13
>> different architectures.
>
> I am forced to an unsubstantiated statement, but I think that more packages and archs
> could be handled without exploding the package manager's size.
> In general, I regard complexity as rarely excused by the size of the task at hand.
> It is something to be tamed, which is a hard enterprise, but is also the essence of computer science, according to some.
>
> This is especially true for an arm machine, where all the efforts of porting an OS on
> could be killed by bloat and waste of the often limited resources.
> Ironically, the current way of having packages in Army Core is to import them from Debian
> through a script written by Core main developer.

 interesting.  so the hard work's done by debian, then they can remove
the complexity and rely on the complexity of debian to make it look
like it's easy in their package manager.

 ... mmm :)

> That's because of the nasty complexity (here, too, I am convinced there is a lot of bloat to cut out)
>  of a typical GNU toolchain, which puts me down, AND because of the lack of a strict policy
> on Core packagers about supplying a buildscript.
>
>> the complexity level is therefore at least three orders of magnitude
>> greater between what tinycorelinux does and what debian does.
> I disagree that the amount of packages/archs is as strongly related to complexity as
> you seem to suggest (rather, it would probably require a more careful separation of each package into -bin, -shared, -lib, -dev, etc...).

 yes.  i think the difference here is between say the approach taken
by slackware and that of debian.  slackware's rule has always been "if
it doesn't compile out-of-the-box with no options, it doesn't go in
slackware".

  at this point i think it would be sensible to move this discussion
to an appropriate debian mailing list, because they will know the
details as to why dpkg is the way that it is.

l.