[Arm-netbook] GK802 for $70

[Paul Sokolovsky]

Hello,

On Tue, 28 May 2013 22:33:33 +0100
"luke.leighton" <luke.leighton at gmail.com> wrote:

> On Tue, May 28, 2013 at 10:14 PM, Philip Hands <phil at hands.com> wrote:
> > "luke.leighton" <luke.leighton at gmail.com> writes:
> > ...
> >>   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.
> >
> > Please don't -- judging from the discussion so far I seriously doubt
> > anyone will be made happier by doing that.
> 
>  *lol*.  yehh.... there is that.
> 
> > As for levels of complexity, you missed another explosion of
> > combinations that dpkg now handles: multiarch now lets you install
> > packages from other architectures, and have packages depend/conflict
> > on/with packages from other architectures.
> 
>  hurhur.  hilarious.  so i can mix amd64 packages with i386 ones yet
> have them run seamlessly because as part of the dependency chain the
> 64-to-32-bit mapping-libraries (which end up i think it is in /lib32
> or somewhere) will *also* get installed.  or i can install armel
> packages on armhf systems and they'll actually work, just through
> nothing more than doing an an "apt-get install".
> 
>  would that be about right?

The primary usecase for multiarch is of course cross-compiling. 2nd
would be emulation support, yeah.

And the fact that first thing which comes to people's mind when hearing
about multiarch is "hilarious" is a good indication that dpkg outmagics
itself and its users. Nope, it's cool that dpkg supports
cross-compilation usecase, but shooting for "cool", there're even
cooler package managers: 

http://en.wikipedia.org/wiki/Conary_%28package_manager%29
(that thingy allows to pin individual files, not just whole packages,
as well as install one file from one package version, and another file -
from another version).

http://nixos.org/
(purely functional package manager, you got it, this doesn't
actually uninstall anything, so you can backtrack to any previous
snapshot of system at any time).

Both above package managers are cool and as needed to real people as
dpkg with all its magic and crutches. It's just some real people don't
know anything but dpkg, so cling to it. Well, based on the discussion,
it seems the only thing needed is just some Debian own hackers to make
some undpkg-debian, and it all will come together as natural. Countdown
begins ;-).

[]

> > If you're doing full system upgrades, with local file diversions,
> > and handling conflicts between conffile edits by the packager vs.
> > edits by the local sysadmin, then you're going to need just a
> > little more code.

Surprisingly, even opkg supports package holds/pins, distinguishes conf
files to preserve user edits, and supports system upgrades. Well, no
surprise, as opkg was done by Debian hackers, who just well understood
that sometimes Debian spirit (having one great distro which runs
everywhere) conflicts with Debian implementation, and the latter needs
to be adjusted sometimes. Folks who descend to cute ARM boards from big
Intel iron don't all get that, but change is coming, I tell ya ;-).

[]

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com