On Thu, Apr 19, 2012 at 17:42, Hans-Joachim Ehlers wrote:

...

2.f) While the sections in the profile seem to be sorted alphabetically by yast,

The original author of the merge.xml has written for us some xslt files. [...] We needed these xslt file to be able todo a merge independent from autoyast.

I'm not too skilled in XSLT; this basically does the same kind of merging autoyast does, right? On Fri, Apr 20, 2012 at 11:50, Uwe Gansert wrote:

On 19.04.2012 15:50, 686f6c6d wrote:

...

1. autoyast generates a lot of messages. For an autoyast dev, this might be wonderful, but dumb users like myself are simply lost in tens of thousands of messages. It makes finding errors in the logs really hard, especially when you don't know what string(s) you're looking for. It would be great if there was, for example, an additional warnings-and-errors-only log.

I know what you mean but it's not autoyast that is so verbose, it's yast as whole. [...] > The loglines start like this: 2012-04-18 14:18:56 <3> 2012-04-18 14:18:56 <2> 2012-04-18 14:18:56 <1> the 3 means it was logged by y2error a 2 means it's a warning a 1 means, it's just a y2milestone (like a 'I was here' message for devlopers).

but I know, reading a y2log file requires some experience

Wow, thanks, that is really useful information! I have noticed these numbers before but could never make heads or tails of them. I assumed they were some kind of "yast hierarchy depth" indicator. *leaves to grep "<[23]>" from recent y2log's* *returns grinning*: 199 (<2>) + 91 (<3>) lines are much better to work with than 56575. (:

...

2. autoyast generates a lot of "noise" in diffs. When cloning a system with yast or editing it manually and then running it through yast again to check for errors, yast changes the profile in various ways. This makes it sometimes harder to see the "real" differences. (In general, one could say everything is fine because the inconsistencies below all "converge" towards a final state, but nevertheless I sometimes wonder why these things happen.)

autoyast transforms the XML file into ycp data structures and feeds those to the yast modules. The yast modules works with those and returns data structures back to autoyast where they are transformed into XML again. There is no information about any order that was in the XML file.

Ah, too bad. So to change this behaviour, the respective yast modules would need to be changed, right?

The yast module often also returns the default values - even if they did not exist in the XML file before. That's important if defaults change. If a key gets lost, it's either not supported anymore or you found a bug.

Ok, I will keep that in mind, investigate further and file bugs accordingly as you suggest below.

...

2.a) (this is new in 12.1 and did not happen before:) for some reason the DNS settings are not kept for stage 2, so I need this script in 12.1:

please open a bug for that

https://bugzilla.novell.com/show_bug.cgi?id=758539

...

2.b)  is _always_ deleted by yast.

you mean the UI always drops that value? That's a bug then. Bugzilla please.

https://bugzilla.novell.com/show_bug.cgi?id=758529

...

2.c) even though a<runlevel>  section exists, the package yast2-runlevel is not automatically installed. [2.d) same for yast2-mail]

that's with every module. Every yast module tells autoyast "In your XML File, I am " So autoyast knows whom to feed with the data from the XML file. [...] AutoYaST itself knows nothing about mail or which module is required to deal with those keys. When you install yast2-mail, then autoyast knows what to do with those keys because the desktop file is there

(Without any knowledge of *yast code:) If that is the case, couldn't autoyast dynamically create a list of section-to-module entries and add these modules? Ah: Reading your comments below, I think I see the problem: This data is in "/usr/share/applications/YaST2/". The module has to be installed already for those files to exist and for autoyast to know anything about the sections. But on the "profile server" side, when creating a profile with YaST, this is also true, correct? So if I assume I can only add those sections whose modules are already installed on the server, couldn't YaST then add those modules involved to the <packages> section? Or are they pumping their sections into YaST "anonymously"?

The good thing with that is, AutoYaST itself does not have to know all yast modules that have autoyast support. You can create an autoyast module without changing anything in autoyast for it. The bad thing about that is, that autoyast can not know what to do with unknown sections. If there is a <runlevel> section but no yast2-runlevel module installed, then autoyast does not know what to do with that section - it ignores it then. Maybe an error popup would be nice in that case.

Yes please, that would be very helpful indeed (doesn't have to be an error though, I would be fine with a warning, too). We have a lot <remove-packages> because we don't agree with openSUSEs default desktop'ish package selection, and so we often run into transitive depencency problems where "Recommends:" (that's just an uninformed guess) like yast* are not pulled in.

Autoyast reads that information from the desktop files in /usr/share/applications/YaST2/

Looking into those files I don't quite understand how it works. (But don't be bothered by that. I'm not sure if I *want* to know. ^^) (Let me get back to you on 2.e etc. later this month.)

...

    2. the order of the<*packages>  and<*patterns>  sections seems to be nonrandom, but isn't nonalphabetic either.

same as 1 maybe. I'd have to take a closer look [...]

...

Does the order of these sections matter?

no, for users and patterns the order does not matter. But autoyast does not know that, so it can not sort stuff like that by itself (well, for patterns that's not true, that really in the autoyast core) but users must be sorted by yast2-users

...

If not, could the please be sorted deterministically (alphabetically, or, f.e., in order of UIDs for the users)?

that could be changed for sure in the yast2-users module packages and patterns are handled in the autoyast core which is code that I maintain by myself.

That's surely a matter of preference, but I think an alphabetic order is much better suited to human debugging. (But it isn't too much of a hassle. Right now I only have to do a ":<,>sort" on these sections in vim).

...

That all sounds so negative. Let me end with a big thank you to all contributors: Thank you. autoyast saves me a lot of time. (:

never mind. Feedback is always appreciated - I don't take anything personal :) I know how frustrating it can be to debug something for days

Thank you so much... Did I mention that I hate Asparagus? Incidently, 12.1 is appropriately named. <; -- Kind regards     686f6c6d / Christopher 'm4z' Holm -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-autoinstall+owner@opensuse.org