[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] what do we do with picobsd ?
In message: <20060131105224.A57698@xxxxxxxxxxxxxx>
Luigi Rizzo <rizzo@xxxxxxxx> writes:
: [i am cc-ing -small because they are interested, but please
: keep the discussion on -current]
:
: as the subject says...
:
: The picobsd script in the tree at the moment is broken in
: several ways. It may work on 4.x, but not on newer releases.
:
: I have a fixed version (mostly the one i attached yesterday, with
: a minor fix to handle the newer boot blocks) that works also
: up to -current. Besides, it relies on ports/sysutils/makefs to build
: the filesystem image so it can run without superuser privs.
:
: I know it is not ideal to have a piece of code in the main tree
: that depends on an external port. Yet, better than have it broken.
:
: Now the options are:
:
: 1. do nothing and leave things broken;
:
: 2. commit the updated script, fix one or two sample targets,
: and remove the others (all of this is in src/release/picobsd)
:
: 3. remove the entire src/release/picobsd tree and move it to
: a port (question - do we want the old content of src/release/picobsd
: in ports/foo/picobsd/files ? In any case, we need a place in
: some repository to store these things)
:
: Option #3 is probably the best one, except that the exact 'config'
: files are strongly tied to the target source tree you are using,
: at least for major releases (libraries differ, application name
: change, etc) and so I'd need to modify the script to reach the
: templates for RELENG_7, RELENG_6... if they are not already in the
: target source tree. Also, this requires a repocopy.
:
: However given that i don't have a lot of time at the moment,
: i would compromise on option #2 for the time being, and move
: to option #3 at a later (but unspecified) time.
:
: comments ?
Given how intertwingled picobsd is to the underly OS, I think you are
going to have a hard time getting to #3. #2 is fine with me.
Warner