image builder: provide a hook for user-defined action(s) while preparing image content

[PeterPawn]

Even if there's already a hook for own actions during image build process (in fwmod_custom), it's somewhat unhandy yet.

This file is currently under source control and local changes to its content lead to a merge conflict (or may at least lead to one), if both files (local and remote) were changed.

The idea is now, to provide the name of such a hook script in the .config file instead.

This prevents conflicts from source control and such files may even be stored in the build system outside of the cloned Freetz tree, if absolute path names or relative ones, pointing outside of the original tree, are accepted here.

I'd like to provide a suggestion for a patch myself (and I will) - but I'd want to poll opinions first, whether this additional hook should replace the existing one from fwmod_custom or whether it should expand it.

Due to the fact, that calling a script outside the own tree is a risk, I personally tend to add a new variable to the configuration template, that defaults to an empty value and which is visible and/or changeable (and finally usable) only for experts or at least advanced users - that means, I would leave the current fwmod_custom calls untouched.

So this one becomes a completely new option and the changes will have no potential, to mislead any users familiar with the current implementation.

But it means, too, that there would be a duplicate mechanism to hook the customizations into the image build pipeline - that's unquestionably a 'contra' and another approach could be, to set the fwmod_custom name as the default value for this hook script.

My "per configuration" approach has (in my opinion) the additional advantage, that different devices with different .config files may use different hook scripts, too. Therefore the fwmod_custom script could be seen more as a "per version" hook (aka "per tree") and this makes - once more - the parallel existence of both hooks looking more convenient/logical for me.

Anyone out there with an opinion or even better ideas?

[er13]

Sorry, I don't understand your description of the different options. From what I understood you would like to add a new symbol to the .config (let's call it FWMOD_CUSTOM_NAME for now). The two options are:

1. Default value of FWMOD_CUSTOM_NAME is empty. Empty value results in fwmod_custom being called.
2. Default value of FWMOD_CUSTOM_NAME is fwmod_custom. If the user doesn't change it fwmod_custom is called.

Is this understanding correct? If so, then I don't see any difference between the two.

If not could you please describe both options once again as short as possible, and if advantageous from the technical/implementation point of view.

[PeterPawn]

I'd prefer to add a new option, which has nothing in common with fwmod_custom - let's call it FREETZ_FWMOD_USER_SCRIPT. It's default value is empty and it's presence or absence does not change anything for fwmod_custom (to keep things consistent).

Instead it gets called from fwmod (the current 'image builder' - in my model, how components in Freetz interact) immediately before or after fwmod_custom with a line like this:

if [ -n "$FREETZ_FWMOD_USER_SCRIPT" ] && [ "$FREETZ_USER_LEVEL_EXPERT" = "y" ] && [ -x "$FREETZ_FWMOD_USER_SCRIPT" ]; then
    $FREETZ_FWMOD_USER_SCRIPT <parameters>
fi

The value has to contain the name of an executable file (-n & -x) and the expert level has to be selected, too, because I would limit this setting to "experts" only and I want to assure, that no "invisible" script with name from an earlier (and re-used) configuration file gets executed without being really displayed in mconf.

I would leave fwmod_custom untouched, if possible. ´This adds a new option (you may use customization scripts, which are not under source control, like fwmod_custom currently is - and this should kept as it's yet) to the image building chain.

I think, fwmod_custom is entitled, too - as a template and example for such customizations and to provide the "all_no_freetz"-options to users, who don't want to change anything beside these options.

But changing this file needs much more awareness from users ... either they copy the changed file from and to the Freetz tree themselves prior/after necessary git operations or they will (or at least may) run into problems while merging changes from Freetz master to their local working copy.

Using a new value, users may even select different scripts for their devices of the same model ... let's call them FB7490_edge and FB7490_office, where each of them needs different customizations for the Freetz image. So the user needs only to specify the correct .config file for each device.

---

In a next step, I'd like to make the used .config file selectable, too - the default name .config requires that the user maintains his configuration files himself (save and replace the default file with the one to use for the current build).

But the programs from Kconfig are able to handle these files by their (different) names ... and there's only another parameter needed to teach Makefile and fwmod (and some, but not much others) to use a different file - at least to copy it as the "current one" itself and take this task from user.

---

My main and seeming still far away goal is a more flexible toolchain, where more than one FRITZ!OS-based device may be served by a single build system and a single working tree - with as least interaction from users as possible.

This is a precondition to get an automated build system in the future, where the user has to provide only a configuration file (and possible customization scripts) and he gets the finalized image.

To make such a system not to have to start over from scratch for each single run, it's necessary to separate the concrete parameters for the requested image (which packages have to be included?) from the model and (FRITZ!OS) version dependent parameters.

Then someone (I, you, we) may re-use the VR9-based toolchain and pre-compiled packages for different models, as long as they're based on the same chipset und use the same toolchain components.

In this context, the new option for customizations at the image builder stage looks best for me.

[er13]

Even more confused. What are the two options your want to discuss / make the decision between?

---

As to the remaining part. It IS possible to build multiple different images within the same source tree. I do it all the time. The only thing one have to do manually is the .config management.

[er13]

An alternative solution would be to add fwmod_custom to .gitignore. This way the local changes would be excluded from any commit unless they are explicitly/proactively staged for commit.

In addition one can add as many additional menuconfig variables as one wants to config/custom.in and make any kind of decisions based on the values of these variables from within fwmod_custom, e.g. call the script $FREETZ_FWMOD_USER_SCRIPT.

I.e. the feature you ask for is actually already possible ;-)

[PeterPawn]

Look - I've started my questioning with the assessment, that there's already an option to customize the image builder, but it's for most users (with little experiences using git) extremely unhandy.

And this is also true for third parties, who'd like to provide "customized files" for such users. Alone the steps needed to ensure the correct files in the proper locations, are somewhat complicated for inexperienced users with the current stand. I did not write, it's "impossible" with the current stand - it's simply "inconvenient".

I think (or hope), I myself know most (not all) of these options and even with this knowledge, the image builder is currently too inflexible in my opinion - it's one of the important reasons, why I'm not using it.

The config/custom.in is located - as one more file - below the "working tree" ... no matter, whether it's excluded from sync with an entry in .gitignore. If you'll use this file, it has to be again the same for all images built from this tree or you have the next file, which needs administration from "outside of the tree".

I don't know, how you're creating your images ... I have to maintain multiple models for multiple customers with different configurations, which share big parts, but are never really the same.

Customization starts with different public keys for verification of integrity of images (used per customer) and ends with different extensions to install - for different branches (offices) or different purposes of a device for a customer.

But I would never ever create a "custom.in" which includes all of the additional options, that are used in sum of all customers - the effort increases exponentially with each new option. Next time each meanwhile added option is detected as "NEW", what frustrates make oldconfig callers and is another obstacle for automated builds without any interaction.

The custom.in is therefore not really an option - I do not even mention the necessary knowledge for creating an own custom.in file, what's another obstacle for most Freetz users.

It's much, much easier to create different files for the different images (the .config files need to be different already, too) and list there all tasks needed for customization ... if there are duplicate entries in different files, it doesn't matter anything.

If the difference in handling is reduced to a different name of the "hook script" in the (anyway) different configuration file, there's no need to juggle with files below the Freetz tree.

My suggestions aren't always for the sake of mine ... I'll usually find my own way to solve a problem. If you think, changes are not necessary anymore, then I'm unable to do anything.

But that you're only able to re-use a build tree for more than one device (or class of devices with same purposes and packages), because you're maintaining the needed configuration files yourself, was written above already (even in #171 (comment) immediately below the first horizontal ruler).

But it looks to me now, as if this is your final goal and the ultimate version and you're not interested in further changes, are you?

Maybe I was too vague with my descriptions or their "preconditions" ... yes, you may RE-USE one single build tree for sequential(!) image builds. But what's about parallel builds on a server with up to 16 cores? The "image builder stage" (aka "fwmod") is neither reusable nor reentrant (that means: usable in parallel).

Such bolides aren't fictional - they are used in automated builds all over and even if Freetz hasn't any continuous delivery or integration parts itself yet (because it needs the concrete configuration from user), it should be possible to use the toolchain or even all parts of the project from such an automated build server - maybe it could be a local one in the first step.

If you accept such automated builds as a goal for the future, you have to separate the settings used in each "stage" of the toolchain ... merging it below the working tree again (no matter, whether in the fwmod_custom or in the custom.in file), is exactly the opposite to what is needed for this goal.

If you don't want to run each build server "from scratch", you have to solve the problem, to conserve a consistent result of earlier stages. This is only possible, if as least as possible customized settings are part of this intermediate result.

If you create a SquashFS image from the toolchain files and mount this file later in your build server for the "package builder stage", you don't need the files to create this toolchain (e.g. the host compiler for the cross-compile toolchain) anymore - this task (creating the toolchain for a given version from vendor) has to be done only once (and for each different toolchain again).

The build system in the "image builder stage" does need neither a compiler nor a complete toolchain anymore - it has only to extract the files from the original image, modify the content of the image tree and create a new packed image. If you have to serve many different devices (same model) with the same FRITZ!OS version and are able to re-use the existing packages from a common build, you may mount the (foreign) filesystem with the precompiled packages and use more than a single instance of the image builder to create as much images as possible in parallel (still from the same Freetz tree) ... usually all of these further steps are just awaiting the finalization of the "package builder stage".

But once again ... all of the suggested changes are only small steps in the right direction. They do not add any complexity to Freetz at all, nor do they change the current implementation.

If you think, everything is fine (or sufficient) as it's now, I'll quit any attempts to untie the strong dependencies between the (imho independent) parts of the current project and Freetz will continue to be a system "only for the experts" (in my opinion and compared with other modern systems - from NAS user interfaces to the tools for rooting of a smartphone).

But there are definitely more users, who would be able to control the build process for their own images, than there are users willing (and able) to "learn" Linux terminal commands. I just can't remember the name of the earlier build service, which was present 15 years ago already - but that's an example, what's my goal and vision for Freetz (that would be really "next generation").

If you want to keep the "status quo" only, I 'm able and ready to accept this, too. But please give me this statement explicitly - I don't want to read any later, that there were no attempts to make things better (or at least different).

Yes, you're right ... there's a (imho unhandy) solution for most problems already. Experienced users should be able to use these options ... but what do you think will all the others do? I will tell it to you: They'll surrender and stop using Freetz - but is this really your vision?

---

And now, to tie thoughts and threads together again ... the core of my question (or more precise of my poll) was, whether it's better to use a new option to implement "per configuration" hooks or whether the old fwmod_custom script should be seen as the "current solution" (and as the default script) and get replaced by the new one.

That a new solution is necessary (one, that's simpler to use and - more important - to create), is unquestionable for me - even if there's already an older (and more complicated) one. If anybody has a better idea (beside the "leave it like it is now"), I would like to read and to discuss it.

This new hook script doesn't need any further decisions or conditional statements ... as long as it's solely customized for the used configuration, it knows already the current settings. That's the main difference to the more general fwmod_custom script, which therefore needs more code to select the right modifications (or which has to be administered from outside the tree again).

If an used script is "smarter" and may cope with more than one configuration ... no problem - but that's not obligated (while it's required for fwmod_custom).

These files have simply different requirements and preconditions, what results in different complexity and the "per configuration" hook scripts are the simpler ones.

[er13]

You mix a lot of things together, please stay within the context of the initial request. Topics like .config management, reusable toolchains, parallel builds within the same source dir might be interesting but nevertheless should be discussed separately.

I do not understand/follow your arguments. What's the problem with e.g. "has to be the same for all images" in

The config/custom.in is located - as one more file - below the "working tree" ... no matter, whether it's excluded from sync with an entry in .gitignore. If you'll use this file, it has to be again the same for all images built from this tree or you have the next file, which needs administration from "outside of the tree".

Yes, the declaration of the variables and thus the content of config/custom.in is the same, but you still assign different values in different .config's.

I believe what you ask for could already be implemented using the current code state:

The whole content of config/custom.in:

config TARGET_BOX_STRING_ID # the name of the customization script is derived from it
	string "Target box Id"

The following additional line in fwmod_custom:

	[ "${TARGET_BOX_STRING_ID}" ] && "/some/path/outside/of/the/source/tree/${TARGET_BOX_STRING_ID}.sh" <parameters>

Does it meet your needs? Is it flexible enough?

[PeterPawn]

I can not skip each context, relations/links and thoughts regarding further directions of development - if a small step with a suggested change is part of an even taller goal. While writing somethings with context I had the hope, that you could see the more complex links yourself.

Please compare the needed efforts of both approaches to solve the following problem (it's from real life, as you know):

• Someone wants to add a single line of code (ifconfig wlan up) to a file (rc.mod) in a single Freetz image - simply for testing purposes.
• He has already more than a single (full-functioning) image and wants to apply such a change only to another single image, but he wants to be able to reproduce this image (with the additional command and/or further changes) as many times as needed (until the problem was solved).
• So he needs additionally a chance to modify the additions (or other changes) with as least as possible efforts - e.g. if more commands are needed or others have to be changed/replaced.
• He doesn't know much about the syntax of shell scripts - someone else provided him the hint, to run the script below via the suggested "user hook" - so he has to store the content below somewhere and to add the path of this file to his .config using mconf (aka make menuconfig). [ Ignore any possible errors in the script below, it was only written down here and not tested. ]

#! /bin/bash
sed -e "87aifconfig up wlan" -i $1/etc/init.d/rc.mod

• He needs the opportunity to keep the current stand of this "test image" (together with all other images he has built in the past) - simply by creating the next image, which has the same needs as the previous one (reproducible, easy to change).
• The task of "keeping an image" from above doesn't mean, he has to store the finalized images - no, there's meant: He has to keep the source file(s) for these images (.config and any other changed file(s)) in a manner, that he's able (as a more inexperienced Linux user) to juggle with them.
• That's most important - only with the stored source files he's able to select a new, different approach to solve his problem, starting with the stand from this source files. Any older (finalized) images are useless here - he has to "prepare" the proper build environment each time, if he wants to build a new image.

As I wrote, this problem is not academically or only theoretically - it was taken from this thread:

https://www.ip-phone-forum.de/threads/rc-custom-in-image-einbinden.303212/

Compare the troubleshooting using my approach (store/change a file, add its name to .config - needed at first attempt only) with your suggestions (to change custom.in and fwmod_custom) and keep in mind, that a problem like this is not a single event. There will always be some inexperienced users, who need help for troubleshooting a problem, that requires (small and simple) changes to their image(s).

As I wrote earlier ... the current approach using custom.in and fwmod_custom is a "per tree" solution. It's applied to all images built from this tree and the script has to be very "smart" to apply such additional changes only to one special image ... but the script will grow and grow, if there are multiple of these "special images", which need special handling. There's no current (configurable) option, that "deselects" changes from fwmod_custom - the script is always called, if it exists.

The new option is a "per image" solution - it's applied only, if it's explicitly selected from .config (the only assumption is, that the image to be built has its own configuration file and perhaps hook script).

You may compare the differences between them with the ideas behind a "site-wide" and a "user-specific" setting from other packages.

The core of my poll was and is still, whether this "user-specific part" should complement or replace the "site-wide part" - the question isn't, whether this "user-specific part" is needed. Sure, you may decide later, that you will ignore a pull request with the resulting changes ... that's why I want to collect opinions, how it's implemented best - but not whether it's necessary.

[er13]

Sorry, Peter, this might be the real case in terms of the problem, but this definitely a constructed case in terms of the solution. It might be your way to solve it but not that of an inexperienced user.

The inexperienced Linux user wouldn't write a sed script to modify rc.mod. He would directly edit the file make/mod/.../rc.mod within the source tree. In case he's interested in keeping the changes for further re-use he would create and save a patch file containing his changes. I can also hardly imagine the inexperienced user would build multiple different images within the same source tree.

Besides that there is a discrepancy in your arguments. In #171 (comment) you write

if ... && [ "$FREETZ_USER_LEVEL_EXPERT" = "y" ] ...

and the expert level has to be selected, too, because I would limit this setting to "experts" only

and in #171 (comment) you are all of the sudden talking about the "inexperienced user". So whom is the new option targeted for?

The inexperienced user would not create any somewhere else located scripts. I could even remember the inexperienced users asking the questions like how to make a script executable, what the correct shebang is, etc. The inexperienced user would definitely directly edit the file.

And the experienced user would do something like I wrote in #171 (comment).

Or to say it the other way

• if you need your own menuconfig options add them to config/custom.in - you're not limited in any way, the whole power/flexibility of kconfig is available. E.g. you can include some kconfig file located outside of the source tree.
• if you need your own modification code add it to fwmod_custom or call any script from there. Calling a script is just one line of code, I can hardly imagine you would get a merge conflict because of that.

In order you're not thinking I'm blocking something for no reason. This is just my view on the topic.

I can perfectly live with adding something similar to #171 (comment) (what you actually ask for is to provide these or similar options out of the box). I would however prefer the replacement alternative, i.e. the default customization script is fwmod_custom, the user may however override it with a custom one (located somewhere else, e.g. outside of the Freetz source tree). Reason: in the long-term view the no-freetz mode should be eliminated completely, i.e. the whole fwmod should be restructured in a way that applying changes not depending on the Freetz framework is possible without the need to activate some special no-freetz mode. In the restructured version fwmod_custom would be empty. The semantic of the option would then be: the user would like to add his own mods to fwmod_custom - the default value suits his needs; the user would like to use his own customization script - he has to override the value of the option with the path to his own script.

[PeterPawn]

So whom is the new option targeted for?

Easy to discover ... look at #171 (comment), where you will read the following phrase:

only for experts or at least advanced users

Later I wanted to keep the shell code line small and simple and omitted the additional test for "LEVEL_ADVANCED" - hoped, you could imagine yourself, how it should look like.

The "group" targeted by the suggested change consists of inexperienced Linux users, who have to decide, whether they may and want help locating a problem (which only occurs on their devices) with the lowest possible additional efforts.

If I (or someone else) may tell them exactly the steps described by me above, they can create such a "special image" for testing purposes ... it's relatively easy and simple to understand and it's a flyspeck compared to the efforts with an additional build tree and changes to one or more file(s), which have to reverted later to get the previous version again.

With your suggestion to use custom.in for this, we're probably nearer than we think ... but from your point of view (due to the use of this custom.in file, what's already the first customization needed for your proposal to work) the whole thing is a "customization", while in my opinion Freetz should provide a (much simpler) hook for such easy tasks.

On the one hand you assess, that's no problem to re-use the whole build tree for more than one image and on the other hand you want to force customizations by the users from within this tree (and the custom.in has to be within this tree, too ... it's only looked-up in the config sub-directory).

Whether you call the user hook script for a special image from fwmod_custom, based on a special "target device id", or from fwmod directly (what unfolds the option, to "replace" the fwmod_custom script with the new hook, while calling it from inside fwmod_custom leads automatically to an addition), doesn't really matter in my opinion - both calls lead to the same result. The only question is (at least for myself), how much changes are needed by the user to gain a benefit from such customizations.

But using custom.in with this "target device id" and a line as shown above from fwmod_custom, adds another (and imho useless or unnecessary) level of indirection to this call - the problem starts with the "fixed path" from your line, in front of the "target device id" part and ends with the additional change required in custom.in.

Sure, "fwmod" needs some changes, too. But if this wouldn't be such a monster of code (I know, that 'modfs' isn't anything leaner) and would use a "more modularized structure", it would be easy to replace this script with an own version, while re-using the components for the needed steps.

Imagine there's a configurable value with the name of this "image builder script" ... it's easy if you try (this was sung by someone).

It would be as easy as stealing the lollipop from a child, if someone could add a list of my "modscripts" to a simple file and call this one for his images via a "hook". And as long as he has an individual configuration files for his images, he may use a different "hook script" for each of them - simply with a single changed value from the configuration file (and with the "original Freetz working tree" without further changes).

And if it gets incorporated into Freetz and is not "marginalized" any longer as a "customization" (because the same result may be gotten on other ways, what's true without any doubt, too), the whole original working tree stays untouched.

At least as far as possible, because using sub-directories of the "source tree" as "working directory" isn't a good idea, too - even if other projects do it in the same manner. That's a "one tree, one purpose, each time rebuilt from scratch" approach and isn't easy to mix with a reusable and possibly reentrant approach, where each stage is only executed, if it's really necessary, because something important has changed for this stage and it needs to re-run.

Such a strategy, to keep original files together and as far as possible untouched and unchanged, is known in other contexts, too - if you have an overlay filesystem with "copy on write" from the underlying structure, you will avoid any unnecessary change to the upper structure - it's more or less the same with a "source tree", if you want it to be reusable for more than one build.

If you compile a package with special "configure" options in-place and store the results below the source tree, the next build with different options overwrites the previous results and if the previous build has to be repeated after another one with alternate options, it has to run from scratch once again.

If you ever want to be able to dissect the parts of Freetz into some smaller (and more handy) pieces, you have to try to replace more and more (currently fixed) settings by configurable values and to clearly distinct between "framework settings", which are needed for Freetz to connect things the right way, and "user settings", which control the manner, how images are built and what they contain.

Currently there's only one mantra from all Freetz files: The "$BASEDIR" is always the working tree with all source files and all further actions are done below this tree.

Why isn't it possible to reuse this source tree (and I mean the same files, not a juggling with links or mounts) for more than one model?

If someone uses own customization nowadays and he wants to support more than one model, he (usually) has to apply these customizations to more than one source tree. Why can't he apply them to the single local copy and the path of this single copy is a configurable setting for the other parts?

I'm juggling with configurations for different models and different platforms for a long time meanwhile (and with many differences to the "original Freetz") ... but it was my private problem in the past and I had to solve it myself. Now Freetz supports multiple platforms itself and more and more users are using more than a single device with Freetz.

In my opinion Freetz has therefore to change some things to make its usage easier - but there will be not a "big bang", after which Freetz gets reincarnated with a completely new structure ... there are many small steps necessary to reach such a goal.

This maybe a mix of different problems again ... but it has to describe and cover the whole situation and to explain, why it's not purposeful to integrate new options for customization of the final image under the original source tree of Freetz - not even such simple changes as the suggested lines from #171 (comment).

And a merge conflict is raised in a jiffy:

peh@vidar:~> cd /tmp
peh@vidar:/tmp> git clone https://github.com/freetz/freetz.git fr
Cloning into 'fr'...
remote: Enumerating objects: 36, done.
remote: Counting objects: 100% (36/36), done.
remote: Compressing objects: 100% (31/31), done.
remote: Total 142239 (delta 9), reused 14 (delta 5), pack-reused 142203
Receiving objects: 100% (142239/142239), 33.12 MiB | 10.57 MiB/s, done.
Resolving deltas: 100% (94543/94543), done.
peh@vidar:/tmp> cd fr
peh@vidar:/tmp/fr> git reset --hard 15d5db5ca5c7da792d3b70892dda1bb0537db5af
HEAD is now at 15d5db5ca fix typo in previous commit
peh@vidar:/tmp/fr> sed -e "54a# my own customization" -i fwmod_custom
peh@vidar:/tmp/fr> git diff fwmod_custom | cat
diff --git a/fwmod_custom b/fwmod_custom
index fbea90f0c..31e3921ac 100755
--- a/fwmod_custom
+++ b/fwmod_custom
@@ -52,6 +52,7 @@ all_no_freetz() {

        # add modfs boot-manager
        source "${patches_scripts}/800-modfs_boot_manager.sh"
+# my own customization
 }

 clean() {
peh@vidar:/tmp/fr> git pull
Updating 15d5db5ca..ebae0e2f1
error: Your local changes to the following files would be overwritten by merge:
        fwmod_custom
Please commit your changes or stash them before you merge.
Aborting
peh@vidar:/tmp/fr>

There's no difference, whether the above was shown with an older commit ... as soon as another change to fwmod_custom was made on upstream, this conflict is raised.

It's no problem for an experienced Git user - but it's an obstacle for most Freetz users, who do know only the "git clone" and "git pull" commands (and who haven't to know more "git" to use Freetz) - and that's not just a boring theory, too.

[PeterPawn]

Hmm ... hier gehen wohl gerade die Uhrzeiten der Kommentare etwas kreuz und quer und es scheint kein Problem der verwendeten Clients zu sein, sondern eher eines des gerade mit der Aufgabe befaßten (Cloud-)Servers.

[er13]

I'm confused a bit, the comments are not shown in the time order. Am I the only one? Or is it a GitHub bug?

[PeterPawn]

Or is it a GitHub bug?

I tend to see it as a server problem.

[er13]

So whom is the new option targeted for?

Easy to discover ... look at #171 (comment), where you will read the following phrase:

only for experts or at least advanced users

Meine Zitat ist aber echt aus dem Kontext gerissen ;-) Die Frage stellte ich am Ende des Abschnitts, in dem ich auf einen Widerspruch (zumindest in meinen Augen) in Deiner Argumentationskette hingewiesen habe. Einerseits sagst Du, die Option sei für die Experten, in den Beispielen redest aber auf einmal über den "inexperienced User". Ein "inexperienced User" ist für mich aber kein Experte...

The "group" targeted by the suggested change consists of inexperienced Linux users, who have to decide, whether they may and want help locating a problem (which only occurs on their devices) with the lowest possible additional efforts. If I (or someone else) may tell them exactly the steps described by me above, they can create such a "special image" for testing purposes ...

Ach so ist es gedacht. Der Experte sagt dem Unerfahrenen und der unerfahrene aktiviert eine Experten-Option in seiner .config :-)

Nebenbemerkung zu testing purposes. Bei testing purposes ist die Erwartung/Hoffnung, dass das Problem in naher Zukunft gelöst wird. Und daher ist es eigentlich egal, wie genau die Änderung erfolgt, die dem Testing-Zweck dient. Der wichtigere Sinn und Zweck von Build-Customization ist etwas dauerhaft / immer wieder machen zu können, was Freetz nicht macht bzw. als eine Option anbietet.

On the one hand you assess, that's no problem to re-use the whole build tree for more than one image and on the other hand you want to force customizations by the users from within this tree (and the custom.in has to be within this tree, too ... it's only looked-up in the config sub-directory).

Die config/custom.in ist nicht under source control, daher sehe ich kein Problem darin. Außerdem wüsste ich nicht, wie man in menuconfig eine Datei inkludieren soll, wo der Pfad zu dieser aus der mit menuconfig erstellten .config kommt.

But using custom.in with this "target device id" and a line as shown above from fwmod_custom, adds another (and imho useless or unnecessary) level of indirection to this call - the problem starts with the "fixed path" from your line, in front of the "target device id" part and ends with the additional change required in custom.in.

Oh, Peter, fang doch bitte jetzt nicht ernsthaft an, die Beispiel-Lösung zu kritisieren (ich habe sogar "these or similar options" geschrieben). Das war doch nur ein Beispiel, dass es mit den jetzigen Mitteln geht und völlig flexibel ist bzw. nur Deiner Kreativität überlassen ist. Die Option in meiner Beispiel-custom.in hätte auch DER_KOMPLETTE_PFAD_ZU_DEM_CUSTOM_SCRIPT oder sogar DIE_LISTE_ALLER_AUFZURUFENDEN_CUSTOM_SCRIPTE heißen können.

And if it gets incorporated into Freetz and is not "marginalized" any longer as a "customization" (because the same result may be gotten on other ways, what's true without any doubt, too), the whole original working tree stays untouched.

Ich nutze privat sowohl fwmod_custom als auch config/custom.in sehr intensiv. Ich habe ein Pool/eine Bibliothek an privaten, nicht-publiken Mods. Für jedes dieser Mods gibt es eine und manchmal mehrere menuconfig-Optionen in config/custom.in (Mod anwenden ggf. mit welchen Parametern). Beide Dateien fwmod_custom und config/custom.in werden in einem separaten (privaten) Repository verwaltet. Die fwmod_custom und config/custom.in unterhalb eines Freetz-Build-Verzeichnisses sind nur Symlinks auf die woanders liegenden privaten fwmod_custom und config/custom.in.

Es ist also wirklich der Kreativität und den Vorlieben des Users überlassen. Du möchtest halt ein oder mehrere Scripte angeben können. Da meine Mods manchmal auch Parameter benötigen, bevorzuge ich die oben beschriebene Lösung.

---

Um die Diskussion mal abzukürzen. Ich habe nichts gegen eine Option, die es ermöglicht, die Namen der aufzurufenden custom-Scripte anzugeben (ob comma- oder space-separated sei Dir überlassen). Der Default-Wert ist fwmod_custom (relativer Pfad wird immer relativ zum Freetz-Build-Root-Verzeichnis verstanden). Möchte nun der User zusätzlich was zu der out-of-the-box angebotenen fwmod_custom machen, so muss er halt die Liste erweitern. Und andersrum den Wert überschreiben, wenn er ausschließlich eigene Scripte ausgeführt haben möchte.

Haben wir damit einen gemeinsamen Nenner gefunden? Oder gibt es noch Punkte, die Dir an dem Vorschlag nicht gefallen?

[PeterPawn]

Ich habe den letzten Beitrag irgendwie nicht mitbekommen als Benachrichtigung - vermutlich durch die (Uhr-)Zeitprobleme zwischendrin.

---

Ich kann mit dem letzten Vorschlag durchaus leben ... um noch mal den Kern meiner "Umfrage" aufzuzeigen: Ich wollte eigentlich nur wissen, ob es Meinungen gibt, wie man es am besten regelt - ob man die alte fwmod_custom erweitert (das ist der einzige Weg, der bliebe, wenn man das - wie bei Deinem Vorschlag irgendwo in der Mitte dieser Diskussion - in der fwmod_custom einbaut) oder ob man das als zusätzliche Option (und nicht "anstatt") realisiert.

Die Lösung an sich ist ja nicht so schwer - ob man das jetzt tatsächlich mit mehr als einem Skript in dem betreffenden Parameter erlaubt oder sich auf ein einziges beschränkt, würde ich immer noch genauer überlegen.

---

Ich sehe den Widerspruch in der "Zielgruppe" immer noch nicht ... daß es diese Gruppe gibt (die eine Art "assisted trouble-shooting" braucht), darüber besteht ja offenbar Einigkeit?

Nun könnte man die von mir ins Spiel gebrachte, zusätzliche Option natürlich auch mit einem weiteren "level of experience" verknüpfen ... nur erschien (bzw. erscheint) mir das auch übertrieben.

Auf der einen Seite will ich verhindern, daß irgendwelche (customized) Dateien ausgeführt werden, ohne daß dieses dem Benutzer "angezeigt" wird (deshalb die Abfrage des konfigurierten Levels beim Aufruf, weil solche Einstellungen ansonsten auch aus anderen Konfigurationen übernommen werden könnten - siehe "clearconfig") und auf der anderen Seite will ich den Änfänger (um "beginner" mal wörtlich zu nehmen), der diese Möglichkeit gar nicht benötigt, auch nicht mit zusätzlichen Einstellmöglichkeiten in "menuconfig" belasten. Für mich liefe das irgendwo unter "build system" und das kommt frühestens mit "advanced" bzw. so richtig auch erst mit "expert" zur Anzeige.

Die von Dir angesprochenen "Unklarheiten" bzgl. der Zielgruppe bzw. der Umsetzung resultieren also aus diesem Zwiespalt - ich dachte (bzw. hoffte) auch durchaus, das bereits in meiner Eröffnung soweit verdeutlicht zu haben ... daher habe ich Deinen diesbezüglichen Einwand eigentlich auch nur zum Anlaß genommen, das noch einmal etwas genauer aufzudröseln.

Einen echten Widerspruch (in meinen Aussagen dazu) kann ich - anders als den Widerstreit zwischen den beiden Extrema bei den Zielen (Übesichtlichkeit vs. Flexibilität), wo man eben Maß und Mitte finden muß - gar nicht so richtig sehen und ich denke mal, daß meine Ausführungen im ersten Beitrag in diesem Thread auch zeigen, daß ich mir genau über diesen Aspekt von Beginn an Gedanken machen wollte - auch dazu lese ich gerne weitere "Meinungen", wie man es am besten realisiert ... ich hoffe mal, daß die vermeintlichen Widersprüche jetzt geklärt sind.

---

Nochmal zur fwmod_custom und der Argumentation, warum diese (aus meiner Sicht) nicht wirklich ausreichend ist. Du selbst hast diese Datei (die nun mal unter SCM-Verwaltung steht) bei der Einführung des "all-no-freetz"-Modus deutlich stärker an Freetz gebunden (und damit aus dem "customizing"-Einfluß des Benutzers gelöst), als Du Dich entschlossen hast, diese "all-no-freetz"-Liste (mehr als eine lineare Verarbeitung ist das ja auch nicht, wenn auch noch mit Abfrage der jeweiligen .config-Variablen) nicht etwa in einer gesonderten Datei unterzubringen (und diese dann anstelle der fwmod_custom aufzurufen - wobei auch hier schon die Frage "anstatt oder zusätzlich" aufgekommen wäre 😎), sondern dafür die bereits vorhandene fwmod_custom zu benutzen.

Du wirst aber sicherlich nicht bestreiten, daß damit und auch durch den Kontext, in dem diese Datei aufgerufen wird (denn sie muß ja so gestaltet sein, daß sie die Patches nur "conditional" umsetzt), ihr Inhalt für einen "unerfahrenen Shell-Benutzer" deutlich unübersichtlicher ist und selbst für den (erfahrenen) Helfer ist es schwieriger, den passenden Ersatz selbst bereitzustellen bzw. "Anweisungen" zum Modifizieren der Datei zu geben - immer mit dem Argument im Hinterkopf, daß sich für die anderen Images, die mit diesem Tree erstellt werden, nichts dauerhaft ändern soll (was die Änderung der fwmod_custom praktisch ausschließt).

---

Da ist der Ansatz mit dem "straight file", das ggf. einfach per Download ersetzt werden könnte und nur Auswirkungen auf dieses eine konkrete Image hat, in dessen Konfigurationsdatei es eingetragen ist, leichter zu realisieren und zu kontrollieren - in der .config steht sogar noch der Name der Skript-Datei, wenn der "Helfer" die korrekte Umsetzung kontrollieren will.

Aber selbst hier gibt es wohl wieder zwei gegenläufige Aspekte ... die Möglichkeit der Angabe mehrerer Skripte macht es natürlich deutlich leichter, einfach ein weiteres für einen einmaligen Test hinzuzufügen, gleichzeitig erfordert das dann beim "assisted trouble-shooting" wieder ausführliche Erklärungen, welche(s) der bisher getesteten Skripte denn nun weiter in der Konfiguration stehen bleiben sollte(n) und welche(s) nicht.

Da ist dann eine einzige Datei (die ggf. ja weitere mit einer einzelnen Zeile aufrufen kann) wieder übersichtlicher (für beide Beteiligte) - so zumindest meine Meinung und schon die Angabe einer recht langen Zeile mit einer Zeichenkette für mehrere Skript-Dateien ist in mconf einigermaßen unübersichtlich und mit viel Scrollen im Eingabedialog verbunden, was wieder viele Fehlermöglichkeiten birgt.

---

Vielleicht kannst Du nachvollziehen, daß aus den oben angeführten Gründen ich tatsächlich mit Deinem Kompromissvorschlag (den ich per se begrüße, weil sich eine Einigung abzeichnet) noch nicht so ganz glücklich bin.

Ich würde eben gerne eine Änderung so ausführen, daß sich für die bisherigen Abläufe so wenig wie möglich (am besten sogar nichts) ändert - den Fall des "all-no-freetz"-Users, der zusätzlich noch im Rahmen des "assisted trouble-shooting" weitere Änderungen (nach "Anweisung") vornehmen soll, ziehe ich jetzt mal nicht noch als Argument aus dem Hut, weil der sicherlich wirklich die Ausnahme wäre.

Jedenfalls steht (m.E.) ja weiter die Argumentation, bei der es nicht ausgeschlossen ist, daß die fwmod_custom im Master erneut geändert wird (durch "all-no-freetz" ist sie eben nicht länger "reines Customizing") und damit der (git-unerfahrene) Benutzer ein Problem kriegt, wenn er eigene Änderungen an der Datei vorgenommen hat. Du selbst beschreibst ja, daß Du zusätzliche Schritte brauchst, um diese Erweiterungen zu verwalten ... denn die Symlinks auf andere Stellen (in dem privaten Repo) sind ja bereits die ersten Anpassungen.

---

Ich sehe es auch überhaupt nicht problematisch, wenn es mehrere Möglichkeiten für solche Anpassungen gibt ... schließlich haben beide Wege tatsächlich einen unterschiedlichen Kontext, ich denke mal, darüber besteht Einigkeit zwischen uns?

Sicherlich käme ja auch niemand auf die Idee, das "vim"- oder das "nano"-Paket aus Freetz zu streichen, nur weil es mit dem BusyBox-"vi" schon einen Editor in Freetz gibt, mit dem man - wenn auch auf anderen Wegen und mit anderen Kommandos, ggf. auch anderem Aufwand - genau dasselbe Ergebnis erzielen könnte.

Der abweichende Kontext (fwmod_custom für alle Images, die mit dem Tree gebaut werden vs. Skript-File aus der Konfigurationsdatei für ein einzelnes Image - was ja auch nicht verhindert, daß man dasselbe Skript in weiteren Konfigurationen verwendet) rechtfertigt es hier in meinen Augen durchaus, daß man das als zwei verschiedene Mechanismen implementiert und das spräche dann wieder für "Ergänzung zur fwmod_custom" und nicht für deren Ersatz.

Das Ergebnis wäre es dann, daß man in fwmod zwei unterschiedliche Formen des "customizing" aufruft (fwmod_custom sogar "unconditional", wie bisher - zumindest wenn das File existiert) und tatsächlich für diese sehr einfach gestrickten, neuen Skripte eine eigene Variable setzt in der .config. Ich würde diesen Skript-Dateien auch nichts weiter als das Zielverzeichnis (build/modified/filesystem) als Parameter mit auf den Weg geben, vielleicht sollte man noch darüber nachdenken, ob bzw. welche Variablen man von fwmod aus exportiert, damit man sie nicht immer doppelt ermitteln muß.

---

Letzteres gilt m.E. auch für das Verhältnis von fwmod und fwmod_custom - die drei als Variablen beim Shell-Aufruf in invoke_fwmod_custom() übermittelten Verzeichnisse sind ja nur ein Ausschnitt der Wirklichkeit und spätestens dann, wenn jemand in seiner (selbst angepaßten) fwmod_custom irgendwelche Entscheidungen in Abhängigkeit von der Plattform oder einer OS-Version treffen wollte, müßte er diese ganzen Informationen erst erneut ermitteln, obwohl sie in fwmod schon bekannt waren. Hier wären ein paar "export"-Statements (einfach als Präfix in einer - finalen - Zuweisung) sicherlich auch hilfreich - zumindest als Angebot an solche Customizing-Skripte.

Bei der fwmod_custom konnte man allerdings noch aus dem Pfad zum Skript (solange man den nicht per Symlink verbiegt, wie Du es wohl machst) das Basisverzeichnis des Build-Trees ermitteln (auch ohne Traversieren von den anderen drei Verzeichnissen, die man als Environment-Variable erhält) - können diese Customizing-Skripte nun aber auch außerhalb liegen und absolut adressiert werden, fällt diese Möglichkeit weg.

[PeterPawn]

Ich habe das gerade noch einmal getestet, was von fwmod (oder ggf. auch schon vom "Makefile", weil ich nicht genauer gesucht habe) im Environment übergeben wird und das ist bisher wohl (nur die mit Freetz- oder Make-Bezug):

NON_FAKEROOT_USERNAME=<user>
MAKE_TERMOUT=/dev/pts/7
FW_IMAGES_DIR=images
FREETZ_BASE_DIR=/tmp/fr
PWD=/tmp/fr/build/modified (gut, das ist nicht explizit übergeben)
FAKEROOTKEY=475979209
LD_PRELOAD=libfakeroot.so
TOOLS_DIR=../../tools
FILESYSTEM_MOD_DIR=./filesystem
MFLAGS=
FWMOD_RECURSIVE=6442
FREETZ_VERBOSITY_LEVEL=2
MAKEFLAGS=
MAKE_TERMERR=/dev/pts/7
PATCHES_COND_DIR=../../patches/cond
MAKELEVEL=1
LD_LIBRARY_PATH=/tmp/fr/tools/build/lib:/tmp/fr/tools/build/lib32
DL_SOURCE_ID=fritz.box_7490-07.08-68239-labor
FAKED_MODE=unknown-is-root
OLDPWD=/tmp/fr

Es gibt also schon ein paar Exporte ... aber die angesprochenen Infos (OS-Version, Plattform, etc.), die ggf. einen Unterschied bei der Abarbeitung einer "gemeinsamen" fwmod_custom erforderlich machen würden, fehlen derzeit.

[PeterPawn]

Questions answered, decisions made ... no further needs to keep this issue opened.

Whether I'll provide a pull request with changes regarding the "ventilated" themes, isn't finally cleared (anymore).

Thanks for other opinions, thoughts and points of view.

[er13]

Ich hatte einfach keine Zeit gehabt zu antworten bzw. überhaupt Deine Antwort zu lesen/zu verstehen, diese ist ja mal wieder nicht gerade kurz geworden.

Ich kann ehrlich gesagt Deiner Argumentation nicht folgen und betone nochmal (vielleicht hast Du diesen Punkt übersehen), dass der no-freetz-Modus nur eine Krücke ist, der langfristig abgeschafft gehört, wodurch fwmod_custom leer wird. Die Abschaffung sollte u.a. dadurch erfolgen, dass der full-featured-freetz Modus optional wird und alles andere, was diesen nicht braucht, jedoch weiterhin in menuconfig auswählbar bleibt.

Ich halte die Lösung mit einer Variable, die die Liste aller aufzurufenden Scripte enthält weiterhin für die beste. Die Schnittstelle zu den Custom-Scripts darf durchaus überarbeitet werden. Das können andere/zusätzliche exports sein, das können auch zusätzliche Parameter sein, sowas wie precheck/mod/postcheck (a la Dein mod).

[PeterPawn]

Doch ... ich hatte das mit dem "langfristigen Abschaffen" durchaus gelesen und verstanden - ich bin ja mit der Utopie, daß der Name des "Image-Builders" auch konfigurierbar sein könnte, darauf eingegangen.

Das wäre dann für mich eine "natürliche Lösung" ... für "no-freetz-mode" wird einfach ein anderes Skript beim Zusammenstellen des Images benutzt (das weiterhin dieselben "Bausteine" nutzt, wie das stärker zu modularisiernde "fwmod") - das hält gleichzeitig das "fwmod"-Skript (oder wie der Image-Builder MIT Mods dann auch immer genannt werden sollte) kleiner und übersichtlicher.

Durch die Benutzung von gemeinsamen Routinen ergibt sich dann auch nur sehr wenig doppelter Code und ob bzw. wo und wie ein solcher Image-Builder dann Eingriffe für Anpassungen durch den Benutzer gestattet, kann man rein durch den Inhalt dieses Skripts festlegen.

Wenn man dann der Ansicht ist, daß zusätzliche Änderungen am Image ein Feature sind, das wenigstens ein "experience level" als "advanced user" verlangt, dann verwendet man eben für "beginner" einen anderen Image-Builder, der gar keine weiteren Anpassungen gestattet.

---

Zur "Liste" der aufzurufenden Skript-Dateien in einer Variablen kann ich nur noch einmal betonen, daß "mconf" einfach nicht wirklich dafür geeignet ist, längere Zeichenketten in einer Variablen zu verwalten - ich habe schon gestandene Linux-User vor den Eingabedialogen von "ncurses" weinen sehen.

Du brauchst nur selbst mal ein solches Eingabefeld (z.B. für den "user defined comment") schön mit Daten füllen, so daß die eingegebenen Daten beginnen, links herauszuscrollen - dann noch einige weitere Zeichen eingeben und nicht zu geizig sein (es dürfen auch zweimal die verfügbaren 70 Zeichen sein + ein paar weitere). Die neuen Daten "kleben" dabei dann am rechten Rand des Eingabefeldes und links scrollt halt ein Zeichen pro Tastenanschlag raus - soweit noch kein Problem.

Aber jetzt gehe einfach mal hin und lösche die zuletzt eingegebenen Zeichen mit der Backspace-Taste, bis Du am linken Rand des Eingabefeldes angekommen bist - und dann noch darüber hinaus.

Was passiert? Jetzt "klebt" der Cursor am linken Rand des Eingabefeldes und jeder weitere Druck auf die Backspace-Taste löscht ein weiteres Zeichen ... nur sieht man das nicht und man hat auch keinen Schimmer (wenn man schön die Finger von den Cursortasten läßt), wann man den gesamten vorhergehenden Inhalt gelöscht hat.

Will man eine solche bereits vorhandene Zeichenkette dann erneut ändern (was beim zweiten Anlauf zum Editieren spätestens der Fall ist), landet der Cursor genau da, wo Du Deinen Test mit dem Löschen gerade begonnen hast ... am Ende des bisherigen Wertes. Außer den Cursortasten und Backspace funktioniert keine weitere Taste zur Navigation in diesen Eingabefeldern (z.B. Home bzw. End).

Und nun überlege Dir mal bitte, vor welche Probleme solche merkwürdig reagierenden Eingabefelder den durchschnittlichen Freetz-Benutzer stellen könnten ... schon die Frage, ob der alte Wert nun komplett gelöscht wurde (immer unter der Annahme, daß ein Scrollen notwendig war und ist), braucht besondere Aufmerksamkeit bzw. das "Wissen" um die Herausforderungen beim Editieren, vor die einen die "ncurses"-Library (konkret auch im "mconf") stellen kann.

Auch wenn man dann selbstverständlich nicht mehr als einen Dateinamen darin angeben müßte, eröffnet so ein Eingabefeld wieder viele neue Fehlermöglichkeiten ... und ich verstehe nicht so richtig, wofür das dann wieder unbedingt notwendig wäre. Es macht in jedem Falle die Bedienung für den durchschnittlichen Benutzer nicht wirklich einfacher.

---

Bis es dann aber tatsächlich mal zu einer tiefgreifenden Änderung für diesen no-freetz-Modus kommt, wird es ohnehin sicherlich noch eine Weile dauern ... ich sehe das skizzierte Problem der leichteren Anpassungen aber heute schon als akut an und würde eine zeitlich näherliegende Lösung bevorzugen.

Zumal auch hier erneut für mich die Frage stünde, warum man sich für ein "entweder oder" entscheiden sollte ... selbst wenn der "mod" am Ende irgendwann mal optional werden sollte, stört die zusätzliche Möglichkeit der Anpassung durch ein weiteres Skript-File des Freetz-Benutzers ja niemanden - der Benutzer KANN es verwenden, aber er MUSS das nicht tun (anders als bisher bei "fwmod_custom", das wird aufgerufen, ob er will oder nicht - ist halt nur ein "dummy", wenn der Benutzer es nicht anpaßt).

---

Außerdem teile ich Deine Ansicht hinsichtlich dieser Aussage vermutlich nicht zu 100%:

Die Abschaffung sollte u.a. dadurch erfolgen, dass der full-featured-freetz Modus optional wird und alles andere, was diesen nicht braucht, jedoch weiterhin in menuconfig auswählbar bleibt.

Wenn ich das nicht wieder vollkommen falsch verstehe, ist das ja auch nicht die Überlegung, die Einstellungen, die man am Ende tatsächlich für den Image-Builder benötigt, von den anderen zu separieren ... hier würde doch wieder gleich am Beginn des Build-Prozesses bereits festgelegt, wie das fertige Produkt aussehen soll, oder? Und nicht nur, wie es aussehen könnte, weil die Pakete A, B und C Einzug in das fertige Image halten dürften, für welche die passenden Binaries (und Hilfsdateien) erzeugt wurden - möglichst noch mit der Option, weitere Permutationen für mehr als eine FRITZ!Box zu wählen.

Wenn ich gleich am Beginn die Wahl zwischen "full-featured with GUI" und "lean modifications" treffen muß/soll und bei "lean" die Pakete, welche das GUI brauchen, gar nicht mehr zur Auswahl angeboten bzw. mitgebaut werden, kann ich die parallele Nutzung desselben Build-Trees für mehr als eine Box (oder gar für mehr als ein Modell mit derselben Architektur bzw. sogar für mehr als eine Architektur, wo der Source-Tree tatsächlich nur noch einmal bei mir existiert - das wäre dann tatsächlich für mich die "hohe Schule") ja wieder vergessen.

[er13]

Das wäre dann für mich eine "natürliche Lösung" ... für "no-freetz-mode" wird einfach ein anderes Skript beim Zusammenstellen des Images benutzt

Es gibt langfristig kein no freetz-Modus. Es ist eine Krücke. Ich mache mir keine Gedanken darüber aus welchen Bausteien eine Krücke gebaut ist.

Zur "Liste" der aufzurufenden Skript-Dateien in einer Variablen kann ich nur noch einmal betonen, daß "mconf" einfach nicht wirklich dafür geeignet ist, längere Zeichenketten in einer Variablen zu verwalten

Ok, das war mir nicht bewusst. Dann könnte man sagen, 5 Custom-Scripte reichen aus und anstatt einer Liste 5 Variablen - jede für je ein Script anbieten. Wäre das eine Lösung?

Zumal auch hier erneut für mich die Frage stünde, warum man sich für ein "entweder oder" entscheiden sollte ... selbst wenn der "mod" am Ende irgendwann mal optional werden sollte, stört die zusätzliche Möglichkeit der Anpassung durch ein weiteres Skript-File des Freetz-Benutzers ja niemanden

Welches "entweder oder"? Wovon redest Du?

• der Benutzer KANN es verwenden, aber er MUSS das nicht tun (anders als bisher bei "fwmod_custom", das wird aufgerufen, ob er will oder nicht - ist halt nur ein "dummy", wenn der Benutzer es nicht anpaßt).

Und was ist bitte schön der effektive Unterschied, ob es "aufgerufen wird und nichts macht" oder "gar nicht aufgerufen wird"?

Außerdem teile ich Deine Ansicht hinsichtlich dieser Aussage vermutlich nicht zu 100%:

Die Abschaffung sollte u.a. dadurch erfolgen, dass der full-featured-freetz Modus optional wird und alles andere, was diesen nicht braucht, jedoch weiterhin in menuconfig auswählbar bleibt.

Wenn ich das nicht wieder vollkommen falsch verstehe, ist das ja auch nicht die Überlegung, die Einstellungen, die man am Ende tatsächlich für den Image-Builder benötigt, von den anderen zu separieren ... hier würde doch wieder gleich am Beginn des Build-Prozesses bereits festgelegt, wie das fertige Produkt aussehen soll, oder? Und nicht nur, wie es aussehen könnte, weil die Pakete A, B und C Einzug in das fertige Image halten dürften, für welche die passenden Binaries (und Hilfsdateien) erzeugt wurden - möglichst noch mit der Option, weitere Permutationen für mehr als eine FRITZ!Box zu wählen.

Sorry, Diesen Absatz habe ich gar nicht verstanden. Und bevor ich da Vermutungen anstelle, die Aufforderung потрудитесь излагать Ваши мысли яснее

Wenn ich gleich am Beginn die Wahl zwischen "full-featured with GUI" und "lean modifications" treffen muß/soll und bei "lean" die Pakete, welche das GUI brauchen, gar nicht mehr zur Auswahl angeboten bzw. mitgebaut werden, kann ich die parallele Nutzung desselben Build-Trees für mehr als eine Box (oder gar für mehr als ein Modell mit derselben Architektur bzw. sogar für mehr als eine Architektur, wo der Source-Tree tatsächlich nur noch einmal bei mir existiert - das wäre dann tatsächlich für mich die "hohe Schule") ja wieder vergessen.

Wieso das jetzt? Wieso vergessen? Arbeite Dich bitte in Freetz ein. Die Auswahl der Pakete zwischen zwei .config's darf sich durchaus unterscheiden, es werden nur die gewählten Pakete ins Image übernommen oder anders rum, die Auswahl eines Pakets im menuconfig ist gleichbedeutend mit "übernehme es ins Image in der eingestellten Konfiguration" und nicht bloß "baue" und dann übernehme alles gebaute ins Image.

Und, wenn ein Paket die Freetz-Infrastruktur für seine GUI benötigt, dann wird es vermutlich nicht angeboten. Aber auch dafür gibt es eine Lösung: sauberer Split auf package und package-cgi.

p.s. Und Peter bitte, bitte kürzer. Wenn Du nur wüsstest, wie Du Dir selber damit schädigst. Du raubst dem gegenüber jegliche Motivation es zu lesen, geschweige denn es verstehen zu wollen.

p.p.s. Und ich könnte damit leben, wenn Du, statt auf diesen meinen Beitrag zu antworten, einfach mal einen Alternativvorschlag in Twitter-Form machst (ohne Argumente), einfach mal wie der Alternativvorschlag aussehen könnte. Es ist nicht ausschließen bzw. in Deiner Wahrnehmung vermutlich in den Kommentaren oben enthalten, aber in seiner vollen Form habe ich noch nicht lesen können.

[PeterPawn]

Wie oben schon mal geschrieben, war das Thema für mich eigentlich durch und erledigt.

Ich kenne jetzt Deinen Standpunkt (andere haben sich nicht geäußert) und überlege mir nun, was ich daraus mache ... ob das am Ende unbedingt in den Freetz-Master einfließen muß oder ob es mir (und denjenigen, denen ich bei einer Fehlersuche damit unter die Arme greifen will) reichen muß, wenn das in meinem eigenen Fork vorhanden ist und per "git pull" genutzt werden kann (wie das auch ohne "git remote" geht, habe ich ja schon mal gezeigt), habe ich einfach noch nicht entschieden.

Wenn Du dann noch einmal nachhakst und Fragen stellst, dann antworte ich halt ... wenn das dann wieder zu lang ist, bringt es ja auch nichts, wenn ich Dir das - noch länger - noch einmal genauer erklären will.

---

Telegramm-Stil ist sicherlich eine Möglichkeit ... aber auch nur dann, wenn der Empfänger und der Absender wenigstens annähernd auf der gleichen Wellenlänge kommunizieren (was ich bei uns heftig bestreiten würde). Ansonsten ist das wie in der Werbung bei der Geschichte der Menstruation ... eine Geschichte voller Mißverständnisse, wie es mal früher in einem Spot hieß: https://www.youtube.com/watch?v=vwMI6uO8j1k - wenn wir schon bei YouTube-Links sind.

Möglich, daß nur selten Nachfragen (von anderen zumindest) zu längeren Texten von mir kommen, weil die kein Schwein liest ... denkbar aber auch, daß ein "etwas weiter ausholen" und Fragen schon von vorneherein dadurch vermeiden, daß der Leser sich nicht nur auf Vermutungen stützen muß, sondern lesen kann, was der Autor meint (selbst wenn der Text dadurch länger ist), solche (Nach-)Fragen einfach überflüssig macht - zumindest in Teilen.

Aber laß uns das hier beenden ... unser "Kommunikationsverhalten" ist es sicherlich nicht wert, ausführlich in einer Issue diskutiert zu werden.