On Sat, Oct 21, 2006 at 09:32:55PM +0200, Dirk Nehring wrote:
> On Fri, Oct 20, 2006 at 10:48:04PM +0200, [EMAIL PROTECTED] wrote:
> > Author: n0-1
> > Date: 2006-10-20 22:48:02 +0200 (Fri, 20 Oct 2006)
> > New Revision: 976
> >
> > Modified:
> > trunk/freewrt/package/Config.in.collections
> > trunk/freewrt/package/bridge-utils/Config.in
> > trunk/freewrt/package/broadcom-nas/Config.in
> > trunk/freewrt/package/broadcom-wl-util/Config.in
> > trunk/freewrt/package/dnsmasq/Config.in
> > trunk/freewrt/package/ez-ipupdate/Config.in
> > trunk/freewrt/package/iproute2/Config.in
> > trunk/freewrt/package/iptables/Config.in
> > trunk/freewrt/package/openntpd/Config.in
> > trunk/freewrt/package/openswan/Config.in
> > trunk/freewrt/package/openvpn/Config.in
> > trunk/freewrt/package/ppp/Config.in
> > trunk/freewrt/package/pptp/Config.in
> > Log:
> > Fixed behaviour of Package Collections to create
> > soft dependencies rather than hard dependencies,
> > as there still should be a way to change earlier
> > taken preselections.
>
> Sorry, does not work, seems to be a build system problem. I revert your
> changes in 1.0 branch, but not in trunk. Your patch is also based on a
> older revision of the files, you revert some of my patches. Please fix
> this stuff.
Ah, seems like I had an outdated version of freewrt_1_0, sorry for that.
Well, my changes are working as expected. After having chosen a package
collection and saved the config, later one needs to be deleted (moved
away) to be able to correctly choose another collection. This is because
the new default values for the affected options are saved inside the
config - and so are interpreted as new (user-taken and therefore
overriding the ones defined in Config.in) default values at the next run
of `menuconfig'.
Defining dependencies to default values is merely ment to get users to a
working basic config, if they don't already have one. I also doubt this
is really what our package collections are ment to be. But as it's also
less helpful to deny later changes to a collection's decision, I thought
about what possibilities there are:
1. Leave the old style
Every package collection contains a `select' for each package. The
user has no chance to deselect them, so they will forcibly go into
the image.
2. Take my current version in trunk
Package collections only change the default for certain packages,
user has full control over what is build and how, but useless in case
of an already existing config.
3. Use a Hack
I tested the following: I defined an internal option like this:
config FWRT_COLLECTIONS_HACK
tristate
default m
select FWRT_PACKAGE_IPTABLES if FWRT_WLAN_DSL_ROUTER_PPPOE
select FWRT_PACKAGE_IPTABLES if FWRT_WLAN_DSL_ROUTER_PPTP
[... and so on for all packages each collection predefines ...]
From the collection choices I removed the `select' statements. This
is something like a "meet in the middle" attempt of the first two
points. Actually, it behaves just like 1., but as `select' only
raises the level of possible choises for the user, it is still
possible to choose a modular build for each package.
BUT: if a user has a config saying "build openvpn as a module", and
then chooses FWRT_OPENVPN_ROUTER, she either might not get what she
wanted.
greetings, Phil
_______________________________________________
freewrt-developers mailing list
[email protected]
https://www.freewrt.org/lists/listinfo/freewrt-developers
