caution! long mail ;-)
On Sep 24 15:07 Dominique Leuenberger / DimStar wrote (excerpt):
On Mon, 2018-09-24 at 14:59 +0200, Johannes Meixner
- all end everything that is useful to run a
for this to work, you need to start with definining
what is a 'web server'. Does it serve pure static content?
Does it understand scripting languages?
I am not at all an expert regarding "web server"
but I think I know sufficiently about "printing"
to be able to define three printing patterns
What nobody can do is to specify that via hardcoded
RPM dependencies in the individual RPM packages.
But I wonder how to define via RPM dependencies in other patterns
what of those "printing-*" patterns should be installed by default
but still let the user choose a different one,
see below about my current thoughts.
openSUSE should not try to cater
to 'all possible variations of needs'
This is not asked for because it is impossible.
What I think is possible is an easier way for the users to
specify which level of functionality they need individually
in each one of their main usage areas.
... the 'problem' is solved via a pattern.
with one pre-tailored to a specific recommendation.
yes, 'a pattern' (i.e. a single pattern) can only define
a single kind of use case.
As openSUSE we have to shine in proposing patterns
as they make sense, without burrying users under them,
making it impossible to pick the right one
to get some work done in the end.
Currently openSUSE is burrying users who like to get a
specific system as they need it under tons of individual RPMs.
The current patterns have already some kind of tree structure.
There are already top-level patterns like "Server" or
"Gnome-desktop" or "KDE-desktop" and there are lower level
patterns like "basic-system" or "Printing" or "LAMP
I think with a better tree based pattern structure it would
be easier for the user to specify what specific system
he likes to get.
The user would start to choose at the top-level patterns
and only if needed go further down to whatever lower levels
in his specific usage areas where he is interested in.
For example usually (unless a user is specifically interested
in a particular lower level area) no desktop system user
should have to deal with what the "basic-system" is or what
any infrastructure stuff like printing or mailing related
In contrast a server system admin would in any case have
to explicity specify what kind of services with what level
of functionality he wants to have on his specific system.
Only as offhanded example assume the top-level patterns
are only "Desktop" and "Server".
The "Server" pattern may have as next level patterns things like
"Networking tools" "X11 server" "Web server" "Mail
As an example I consider the "Desktop" pattern in more detail:
The "Desktop" pattern may have as next level patterns like
"Gnome desktop" "KDE desktop" "Xfce desktop" ...
Each of those "<specific> desktop" patterns may have as next level
"<specific> desktop minimal"
"<specific> desktop recommended"
"<specific> desktop full"
Each of those "<specific> desktop <level>" patterns may have as next
"Video and Audio"
Each of those "<functionality>" patterns may have as next level
Those "<functionality> <level>" patterns may finally require the
normal RPM packages that provide the particular level of functionality.
When the user chooses only the top-level "Desktop" pattern
he should get a default desktop system installed i.e. the default
desktop with its associated "<functionality> recommended" patterns
that result the default set of normal RPM packages.
On the other hand it must be possible for the user to change
anything in that default selection as he likes.
I wonder how to define that via RPM dependencies only in the
patterns because the RPM dependencies in normal packages
should only be RPM requirements for the essential stuff.
Because the "Desktop" pattern must have a RPM requirement for one
of the "Gnome desktop" "KDE desktop" "Xfce desktop"
it cannot require one of them directly because otherwise the
user could not change what specific desktop gets installed
(RPM recommends would be wrong because it is a fatal error
when the "Desktop" pattern would not result that a desktop
gets actually installed).
I think the "Gnome desktop" "KDE desktop" "Xfce desktop"
must provide a common RPM capability e.g. named "specific_desktop"
and the "Desktop" pattern requires "specific_desktop".
Now I wonder how to define the default provider
of that "specific_desktop" RPM capability.
I am not a sufficient RPM expert to answer that question.
I would hope the default provider could be specified by an
artificial version of that "specific_desktop" RPM capability
so that zypper would choose to install the pattern that provides
the highest available version of the "specific_desktop"
If this works things could even automatically behave well
depending on what is available to be installed.
"Gnome desktop" provides "specific_desktop version 100"
"KDE desktop" provides "specific_desktop version 120"
"Xfce desktop" provides "specific_desktop version 80"
and all are available to be installed, then the "Desktop"
pattern should result that KDE gets installed.
When e.g. KDE would not be available to be installed,
the "Desktop" pattern would still do "the right thing"
and result that Gnome gets installed.
I think in the end the problem is how to define
the patterns reasonably well.
I neither say it is easy nor it can be done quickly.
But I think it is possible.
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org