Andreas Jaeger wrote:

Rajko M writes:

...

This time I was little bit more thorough logging what I have seen.

I like 1 CD installation. It loads basic system fast and than I can add whatever I want. I tried that with 10.2 alpha 4, but it doesn't work that way.

I know - and this will happen only with Beta1 again. First we need to get the patterns list fixed.

OK. I guessed that was the reason, but direct answer will help not to repeat the question. ...

...

3) So I quited installation, added another 3 CDs and tried to install Base + AppArmor + Console. It gives > 1 GB including some KDE files and requires all 5 CDs. I didn't checked what was from KDE, I remember kdelibs. I guessed that Console means text mode and few more applications like "mc", not graphic mode Console. I interrupted installation at that moment. Package dependencies seems to grow system to classic bloat.

Please discuss the list of patterns and what you propose to change. I want to avoid bloat!

I have to go trough above pattern, to see what happened, before I can discuss anything. BTW, it might be good to sort results of previous thread on basic pattern and repeat the question. Something like phase 2. ...

...

7) Audio was not installed. I can't recall that it was ever mentioned. The adapter is plain VT8233/A/8235/8237 so something with detection wasn't OK. Taking long list of: udev[411]: lookup_group: <misc devices> not found (or missing), during initial hardware detection, it can be that.

yast2-sound was not installed - fixed now.

Thanks.

...

9) The Main Menu is huge. Font is now OK, but surface is far beyond screen. Restarting KDE doesn't help. Go back to mc and find in users .kde directory kickerrc. Menu size was KMenuHeight=1950 KMenuWidth=3160 resize to 400x600 and restart KDE again. Menu is good now. This must be due to same 28x21 (cm) screen size that is probably bad entry in monitor DB.

Please report this in bugzilla.

...

12) gcc is not prerequisite (dependency) of kernel sources. If gcc is not installed what can I do with sources?

Read them ? ;-)

What about to fix prerequisites :-) Is it fixed (?). ... -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rajko M writes:

What about to fix prerequisites :-)

Is an option but do we really want this? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Hi, Rajko M schrieb:

That is reason to ask for gcc. I know how to handle this, but new to Linux will get lost, and we will have to handle a lot of help requests from them.

PLEASE. The web is full of - forum posts - wiki entries - other documentation resources which clearly say: "In order to compile a kernel module, the packages gcc, make and kernel-source are needed." The user will "get lost" only if he's not interested in getting the job done anyway.

Another option is weak dependency, as Christian mentioned, but I haven't seen recently packages that will be installed to satisfy dependencies and have check box enabled, which would be sign that I can remove them from selection.

That's because "weak" dependencies are not weak at all. There are just two cases: - The package that another package depends on is installed by default. This is the case with "Requires" and "Recommends". "Requires" == "Recommends" here. - The package that another package depends on is not installed by default. This is the case with "Suggests". "Suggests" is very similar to not having a dependency at all. There is no intermediate step between these and no way to prevent a "Recommended" package from being installed other than installing it and uninstalling it again or setting the package to "taboo" - which requires the user to know in advance that the dependency is meant to be "weak". I can explain why I don't like the idea of kernel-source depending on gcc: It breaks the concept of being able to replace the system compiler that has just now been introduced, because it will force the system compiler to be installed even if the user already has another compiler. On the other hand, you might argue that kernel modules must be built with the system compiler anyway... And that's correct. So maybe the proposal makes sense, but I'm unsure. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rajko M schrieb:

If this, about system compiler, is hard fact, than there is nothing to be unsure about. I don't like few hundreds MB more, just to be able to run video adapter in full featured mode, but if I have to, then there is no options. I either have kernel sources and gcc installed, and used, or I have no 3D, and for instance Google Earth runs skipping the frames (nvidia with nv driver) or not at all (old ati board with ati driver).

So you really, really want gcc to be installed by default together with kernel-source, and it is unacceptable to the well-known novice user that he must figure out that a compiler is needed in order to compile a kernel module? OK. But then, make must be added there as well, because gcc and make are exactly equally required in order to compile a custom kernel or a module for the currently running kernel. Adding gcc, but not adding make seems nonsensical to me. A few offtopic remarks: - Alternative package managers like smart, apt and yum will completely ignore "Recommends", while zypp will handle it almost like "Requires". This behaviour difference might confuse users and is one of the reasons why I'd like to see the use of "Recommends" restricted to special cases. - While investigating the Factory tree for this issue, I found out that a few -devel packages already have hard dependencies to gcc while others don't have them at all. It would be nice if there could be some sort of policy. Proposal: - -devel packages should not have any dependencies to any compiler, neither weak nor hard, in order to allow replacing the system compiler easily without breaking dependencies. - package kernel-source needs more discussion; adding a dependency to gcc and make here is IMHO actually more useful than the gcc dependencies within -devel packages. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Andreas Jaeger schrieb:

Just use the kernel development pattern and install it - you get everything directly.

Wait - the kernel development pattern includes more packages than needed for just building external modules, including large and potentially undesired ones like kernel-debug and kernel-um. The user might end up with kernel-debug being booted by default. So this pattern is the right thing for developers, but not for users who just want to build their favorite gfx driver. Adding yet another smaller pattern with just kernel-source, gcc and make for building external modules is probably overkill, we should not explode the number of patterns infinitely.

...

- package kernel-source needs more discussion; adding a dependency to gcc and make here is IMHO actually more useful than the gcc dependencies within -devel packages.

Could any of you file a bug, please?

Maybe I'll do it once I'm really convinced that doing this is a good idea ;-) Or someone who is already convinced, go ahead and do it. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Robert Schiele schrieb:

Does this happen with the current package?

Yes, installing kernel-debug on a Factory system where there was only kernel-default installed renames the existing vmlinuz and initrd symlinks to .previous and creates new ones pointing to kernel-debug, effectively making kernel-debug the default. The conclusion is that the kernel development pattern is not the right thing for users who just need to build an external module.

If so, I'd consider this a bug and you might want to file a bug report.

I won't file a bug report because I'm not sure that this is a real bug. It makes sense, someone who installs kernel-debug most likely wants to use it, and someone who doesn't want to use it should rather not install it. Unfortunately, it renders the kernel development pattern a no-go for just building external modules, and that in turn backs the point of having kernel-source depend on gcc and make, so that users can install a single package to get a complete kernel module build environment. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, 14 Sep 2006, Andreas Jaeger wrote:

Andreas Hanke writes:

...

Robert Schiele schrieb:

...

Does this happen with the current package? Yes, installing kernel-debug on a Factory system where there was only kernel-default installed renames the existing vmlinuz and initrd symlinks to .previous and creates new ones pointing to kernel-debug, effectively making kernel-debug the default.

The conclusion is that the kernel development pattern is not the right thing for users who just need to build an external module.

So, should I change the pattern? I can make kernel-debug completely optional...

I know that we probably do not want an other pattern but given all the issuses maybe an other pattern would be the best solution. "Modules extrenal build" I really would like to keep the debug stuff in the kernel-debug. When I have to debug kernel issues, I really want the complete stuff even with the debug being the default kernel to use. Just my $.02 -- Boyd Gerber ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, Warren Stockton schrieb:

It would be great if kernel-debug could be made optional AND 1) if it can also co-exist with kernel-default

What does co-existance mean in this context? Multiple kernel packages can already be installed in parallel - do you mean something else?

2) have its own bootloader entries rather than stealing /boot/vmlinuz and /boot/initrd

Installing any kernel package in addition to an already installed one does the following: - Rename the existing vmlinuz and initrd symlinks to .previous - Create new vmlinuz and initrd symlinks pointing to the just installed kernel - Create a new bootloader entry named "Previous kernel" pointing to the .previous symlinks Changing this behaviour for kernel-debug is questionable because the same script is being used for all kernel flavours. It would be some work and also a bit inconsistent IMHO - currently the last installed kernel "wins", but the previous one is still available.

It would also be great if crash Require'd kernel-debuginfo. The kernel-*-debuginfo packages would need to Provide kernel-debuginfo, so that when crash was selected for installation the correct kernel-*-debuginfo was selected based on the currently installed kernel (default or bigsmp)

This is not trivial because the -debuginfo packages are autogenerated by a script. I don't know if it's even possible to add dependencies manually for these packages. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Andreas Jaeger schrieb:

So, should I change the pattern?

Let's not hurry. ;-)

I can make kernel-debug completely optional...

Maybe. That might be an option for other reasons as well - I tend to find a pattern changing the default kernel rather obtrusive and maybe surprising, because not all KMPs are available for kernel-debug. The user might end up with effects (missing modules...) that he did not expect. On the other hand, I'd like to hear more opinions of people who will use this pattern for actual development purposes and not just building an external module. How much sense does the pattern make without kernel-debug being installed by default? Some brainstorming why this discussion started: There was a request to simplify the way of getting a build environment for external modules (3D gfx drivers in particular). This request is legitimate. There are multiple proposed solutions: 1) Advise the user to install packages gcc, make and kernel-source individually. Advantage: Is simple, will always work for everyone under any circumstances, is portable across all earlier and future openSUSE distributions and even foreign distributions, does not introduce any avoidable overhead on the user's machine. => Easy to support. Disadvantage: Some manual intervention needed. 2) Change package kernel-source to have a soft or hard requirement to gcc and make. Advantage: Is simple. Disadvantage: Significant change compared to earlier SUSE releases, a soft requirement will not work with other package managers than zypp. 3) Advise the user to install the kernel development pattern. Advantage: Is simple. Disadvantage: Will introduce overhead on the users machine - packages which clearly belong into this pattern, but are not needed for external module builds; will change the default kernel. 4) Create a new pattern that includes just the bare minimum needed to build external modules. Advantage: ? Disadvantage: Bloats the already impressive number of patterns even further. 5) Reduce the kernel development pattern to make kernel-debug optional. Advantage: Avoids the default kernel switch (see 3), maybe desirable even independently of this issue. Disadvantage: Will still introduce other packages than kernel-debug that are not needed for external module builds either; might be perceived as degrading functionality of this pattern; first negative feedback from an actual kernel developer already there. I'd go for either 1), 2) or 5), based on more opinions from different people.

From a user's perspective, a one-click solutions is desirable, but I wouldn't call it something that "must" be done. Sticking to 1) is not catastrophic if a better and universally acceptable solution is not found.

Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, Sep 21, 2006 at 01:39:43PM +0200, Andreas Jaeger wrote:

...

On the other hand, I'd like to hear more opinions of people who will use this pattern for actual development purposes and not just building an external module. How much sense does the pattern make without kernel-debug being installed by default?

Nobody has answered so far - so what should be done?

As I already mentioned would consider kernel-debug installed as the default kernel a bug and thus would handle it in a similar way as the xen kernel in the postinstall script. If you do so it can no longer hurt anyone installing it by accident because it has to be booted in an explicit way if wanted. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

On Thu, 21 Sep 2006, Andreas Jaeger wrote:

Andreas Hanke writes:

Nobody has answered so far - so what should be done?

...

4) Create a new pattern that includes just the bare minimum needed to build external modules.

Advantage: ?

Disadvantage: Bloats the already impressive number of patterns even further.

So, what do you all think?

I said, I prefered this one. I tend to find a pattern changing the default kernel rather obtrusive because not all KMPs are available for kernel-debug. The user might end up with effects (missing modules...) that he did not expect. And could be rather hard for a non advanced user to deal with. -- Boyd Gerber ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, Am Mittwoch, 13. September 2006 01:10 schrieb Rajko M:

Andreas Jaeger wrote:

...

Rajko M writes: [...]

...

12) gcc is not prerequisite (dependency) of kernel sources. If gcc is not installed what can I do with sources?

Read them ? ;-)

What about to fix prerequisites :-) Is it fixed (?).

What about adding gcc and make as weak dependencies to kernel-source? "Recommends" would be a good option IMHO. BTW: I just wonder that kernel sources from 10.1 (didn't check 10.2 yet) require /sbin/insserv - did I miss something or is this a packaging bug? Regards, Christian Boltz -- printk("; corrupted filesystem mounted read/write - your computer will explode within 20 seconds ... but you wanted it so!\n"); [/usr/src/linux/fs/hpfs/super.c] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Andreas Jaeger wrote:
> Rajko M  writes:
...
>> 9) The Main Menu is huge. Font is now OK, but surface is far beyond
>> screen. Restarting KDE doesn't help. Go back to mc and find in users
>> .kde directory kickerrc. Menu size was
>> KMenuHeight=1950
>> KMenuWidth=3160
>> resize to 400x600 and restart KDE again.
>> Menu is good now. This must be due to same 28x21 (cm) screen size that
>> is probably bad entry in monitor DB.
> 
> Please report this in bugzilla.
...
Reported:
1) Missing HD as installation source:
https://bugzilla.novell.com/show_bug.cgi?id=205369
2) Incorrect screen size for monitor Gareway EV500.
(should be Gateway :-) sorry)
https://bugzilla.novell.com/show_bug.cgi?id=205371
3) Huge Main Menu
https://bugzilla.novell.com/show_bug.cgi?id=205373

-- 
Regards,
Rajko.
Visit http://en.opensuse.org/MiniSUSE
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-factory+help@opensuse.org

Stanislav Visnovsky wrote:

Dňa Ut 12. September 2006 05:40 Rajko M napísal:

...

This time I was little bit more thorough logging what I have seen.

[snip]

...

5) It is already mentioned that partitioning proposals are given in a strange way. First it tried to remove 10.0 installation from /dev/hda1, and create two partitions, than tried to remove data partition, on the same disk, than I stopped to play with different menu options and went to expert and gave /dev/hdb1 for installation. Partitioner warned me that it will be better with swap. Good, swap exists, I added it buy entering dialog where all was set just to click to OK and exit. This might be somewhat shorter, and just explain that we need a swap and ask which one to include.

Please, file an enhancement into bugzilla. ....

There is another thread "Partition selection openSUSE (install)" that is discussing this. Right now I would make only one screen out of two that experienced user has to go before it comes to expert partitioning. Later we can discuss what is the best way to handle multiple partitions. Right now the safe way would be to ask the question instead to give proposal if it is not clear from partitions. Is above OK to go as enhancement request? -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org