* Pascal Bleser
Now, with those patterns, if they're not a closed, well-defined list of options to choose from, we will most probably end up with chaos.
Well, actually I don't think so. We'll probably get as much (or better as less) chaos as with packages. Patterns is about the ability to group packages for better overview and handling, mostly at the UI level. Its an abstraction level. However, I do agree that some kind of public 'pattern database' would be nice in order to find duplicates and overlaps. Consider pattern P requiring package a,b,c,d and e. And pattern Q requiring a,b,c,d and f. With a database, one could see the a,b,c,d overlap, create a pattern R with a,b,c,d and let P require R and e and Q require R and f.
- The groups can be specified as comment-metadata at the top of the spec file
Well.. yeah... that should be the last option to consider. Introducing proprietary spec file tags through comments is really, really bad practice.
I fully agree. The package-pattern relationship is not an attribute of the package.
Anyhow, that pattern infrastructure must be "pluggable" - i.e. every package must be able to define what pattern it is part of.
Please let the patterns define which packages they want. Grouping of packages is already done with RPM groups. Being able to specify multiple groups would be nice. But this does not specify (hard or weak) dependencies and there's no use in enforcing specific package groups to be installed. However with patterns, defining a functionality, dependencies express to-be- installed packages and the dependency solver ensures this.
I think it would be much better to just store the information directly in .pat files in repositories (in suse/setup/descr), in a simple format, to just create or modify those files with a simple text editor (XML would be an option as well - less human-readable/editable but validation would be a plus).
Agreed. Lets create a 'pattern definition format' (just like .spec is a package definition format)
An example: - - you have two repositories configured in your list: SUSE Linux 10.2 and Packman (for SUSE Linux 10.2) - - in the SL 10.2 repository, in suse/setup/descr/, you have a file called "development-database-server.pat", that includes stuff like mysql, mysql-Max, postgresql-server, ...) - - in the Packman repository, in suse/setup/descr/, you also have a file called "development-database-server.pat", that includes e.g. firebird
Well, thats similar to packages having the same name but different content.
YaST2 must be capable of iterating through all the .pat files of all the repositories it has in its configuration, and to merge to actual list of packages that are part of each pattern from all of those.
For the example above, the "Development/Database/Server" pattern should contain/show - - mysql - - mysql-Max - - postgresql-server - - firebird
Given the package analogy above, would such a merge behaviour make sense ?
On another note, I hope the process and behavior will be well-documented. It would be really neat to also implement pattern support into smart, for example. smart upgrade pattern:Desktop/KDE3
'rug' is already able to do exactly this ;-) Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org