On Tue, 13 Apr 2010 09:12:48 +0100
Neil Williams codeh...@debian.org wrote:
One further thing with Baked - it's not reasonable to assume that
users of Baked can combine packages from Crush or Grip directly into
Baked. Users of Baked would have to first check whether the packages
contain features
On Tue, 13 Apr 2010 10:10:07 +0100
Neil Williams codeh...@debian.org wrote:
Further idea for Baked:
Instead of doing a brute-force 'rm -rf' of the dpkg and apt metadata
after a multistrap install, it's as easy to do 'rm' as it is to do 'mv'
from the rootfs to somewhere outside the rootfs. That
Longtime lurker here.
Overall I think this is an excellent idea.
I can validate that there is use for this approach, since it parallels
in many ways the roll it yourself method for maintaining a small
embedded baked distribution currently used by a commercial product I
work on. Once the
On Tue, 13 Apr 2010 07:39:24 -0400
Jim Heck js...@heckheck.com wrote:
On 4/13/2010 4:12 AM, Neil Williams wrote:
The expectation would then be that multistrap would work with such
local repositories to impose the relevant configuration using device
table files, pre-configured files to go
No. Not at all. In Baked, the entire system configuration is up for
grabs - if you don't implement it, it won't exist.
Multistrap won't have any preinst or postinst scripts to run - the
baking process happens in two stages:
1. Packages are baked by emgrip and put into a (local) repository
2.
On Tue, 13 Apr 2010 08:24:01 -0400
Jim Heck js...@heckheck.com wrote:
Not as preinst and postinst, you'd simply write a script that does the
entire job for all packages in one step.
Does this mean that there won't be an opportunity to keep these scripts
granular per package?
Better
On Tue, Apr 13, 2010 at 9:32 AM, Neil Williams codeh...@debian.org wrote:
Does this mean that there won't be an opportunity to keep these scripts
granular per package?
Better to have scripts that are granular per device variant.
I was suggesting that instead of having a single monolithic
On Tue, 13 Apr 2010 10:38:07 -0400
Jim Heck js...@heckheck.com wrote:
On Tue, Apr 13, 2010 at 9:32 AM, Neil Williams codeh...@debian.org wrote:
Does this mean that there won't be an opportunity to keep these scripts
granular per package?
Better to have scripts that are granular per
On Tue, 13 Apr 2010 14:32:47 +0100
Neil Williams codeh...@debian.org wrote:
With the 'mv' instead of 'rm' feature, you would have a copy of the
original scripts (which include the package name in the filename) but
then you've still got the original problem - you cannot run the
maintainer
Hi,
On Tue, Apr 13, 2010 at 09:13:56PM +0100, Neil Williams wrote:
Change of plan - or at least a clarification. The 'mv' support is for
the final files created by dpkg - /var/lib/dpkg/status - not the
maintainer scripts themselves, those will have gone from the packages
being downloaded.
On Tue, 13 Apr 2010 23:33:24 +0200
Simon Richter s...@debian.org wrote:
On Tue, Apr 13, 2010 at 09:13:56PM +0100, Neil Williams wrote:
Change of plan - or at least a clarification. The 'mv' support is
for the final files created by dpkg - /var/lib/dpkg/status - not the
maintainer
11 matches
Mail list logo
