Jeremy Katz wrote:
A few thoughts...
On Wed, 2007-07-25 at 18:06 -0500, Douglas McClendon wrote:
> I know there may already be some similar functionality already in revisor, this
> patch adds it to livecd-tools
> The two new options are
First off, at a glance, the options just look like gobbledy-gook to
me :-) In cases like this, it's almost always better to spell out what
is meant rather than an abbreviation that isn't immediately obvious.
aesthetics. rename however you like.
The second thing is that having this as command-line options leads to
increased chance of the live image build not being reproducible. As
much as possible, the movement has been to specifying things within the
kickstart config rather than having command line options for specifying
I think this is where ideals meet practicality. But to work with you, would you
be happier with a patch, where say, instead of --addsdir, there was
--add-user-system-data, which behaved exactly the same, but the implementation
mechanism included rolling the directory into a dirt simple noarch rpm with
almost no data in the specfile? I.e. do the rpmbuild -bs, rpmbuild --rebuild,
and createrepo for the user?
I suppose it really isn't that hard (though it will be months before such a
thing makes it to the top of my priorities).
In fact, I'd like to overall entirely deprecate the use of most of the
command-line arguments in favor of having them specified in the
kickstart config. And at the same time, I also want to look at making
sure that we include the kickstart config on the image that's created so
that people can more easily see how the image was created, modify it,
and then create their own. What do other people think of this? The
things which really "matter" which aren't currently expressed in the
config are prelink and the uncompressed size of the rootfs. The latter
is easy (we just add interpretation of part / --size ...). Adding the
former is probably not terrible to do either.
> Both may be invoked any number of times. The contents of the directories
> specified, will be copied to the target livecd. addsdir adds the contents to
> the rootfs of the target, while addidir adds the contents to the iso9660fs of
> the target.
Then when and what of these occurring seems fine. Although I wonder if
we'd be better off just making it so that you could do %post --nochroot
and also moving %post to be run later
I just saw a mention on kickstart-list, about using just such a scenario, and
wondered if it was really possible. Of course, as far as reproducability goes,
it is a bit wonky, as %post --nochroot seems to me to be just as much a supreme
breaking of reproducability as the --addsdir thing. I.e. the environment
outside the chroot, is going to be entirely different for every build
(especially traditional anaconda kickstart usage, versus livecd-creator usage).
Also, in my opinion, adding things to the isodir really has /nothing/ to do with
the system being defined in the kickstart, and really should be separate (maybe
even separate tool, 'livecd-repacker'?). I mean, suppose you want to roll your
own mp3/ogg library on your CD. Not the sort of thing that seems appropriate
for a kickstart.