Re-targeting the list.
---------- Forwarded message ----------
From: Jeff Mitchell <skeezix(a)skeleton.org>
To: "[ISO-8859-1] S�bastien Huss" <sebastien.huss(a)gmail.com>
On Fri, 25 Feb 2011, [ISO-8859-1] S�bastien Huss wrote:
# The nice thing of having the filesystem at first and the rest appended at
# the end is that the filesystem is immediatly available to be mounted : no
# need to do ugly hack to have mount to see the filesystem
Actually the loopback mechanism (these days, not years ago) can
usually take an offset, so you canhave a binheader and not too much work
.. as long as calculating where the filesystem is is easy :)
# > - payload filesystem change;
# Might be nice, but does zipfs support Unix like priviledge-system ?
Support enough I think; I doubt pnd_run.sh itself cares about the
appended parts, just the main payload; but libpnd cares about the appended
stuff, and its easy to read a basic zip, without mounting zipfs.
I've often thought it would be cute to do iso+zip, with the zip
part having one PXML.xml or the .desktops, and icon(s), and anything the
dev wants to publish easily (audio clip or screenshots.)
# > - appended format;
# That sound like the simplest, yet best solution so far. No change to
# pnd_run.sh, only adding the previews and the icons there. sdound resonable
# for me and will fixes thoses little limitation we have currently
It'd be easy to add to libpnd.
In fact, I added iso/squash/whatever+zip in a couple of times a
year ago, its very easy.
Folks in IRC tended to dislike the idea though, so its not in
place, but it could be.
atc -- your time to speak up!
# > - theres 'crazy like a fox' ideas too;
# >
# the thing I like here is that you could then have a modified bitbake to
# build pnd more easily than with current situation. But all these overlay is
# the best way to shoot into your feet imho. (once you start 2 apps and
# more...)
You could just use debian packages at this point too, or other
crazy tricks; but having 300 overlays is just not going to work imho :)
Still, floor is open for other ideas; I admit, I'm ovrworked and
fried in the end, so really outrageous creative solutions aren't coming to
mind for this .. so its very possible some truly awesome idea is out
there.
But that side, the conventional ideas I think I listed there.
So I'm a bit of a fan of iso(whatever)+zip, but I've also not
actually run down the pros/cons yet to see if its a worthy addition.
filesystem + zip-appended
Pro:
- doesn't fight with current system
- trivial to add with no user confusion
- improve performance of some operations, with changes to libpnd
to understand it; ie: fast fetch of screenshots
Cons:
- still goofy filesystem plus something, which I don't personally
mind
Before we consider acting on that, best to consider all the
options, and pick the best overall one. Just adding this one would end up
with two systems, and then if we find a better, we'd have 3 ... better to
let it sit, and find a better solution, and go to that.
I also like libpnd nice and simple, so we can hack on it and
grow/change it easily, with little baggage; keeping it simple makes for
speedier adoption by developers, reliability makes it adoptable by users.
Complexity is bad for both scenarios.
So libpnd hasn't changed pnd-files since inception a year or two
back, but thats okay. We want adoption.
But nows a good time to figure out if there is changes to be.
jeff
--
If everyone would put barbecue sauce on their food, there would be no war.