-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaus Kaempf wrote:
* Pascal Bleser
[Jul 23. 2006 12:42]: [...] 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.
I think we have a slightly different view/understanding of the patterns. To me, it's not as much high-level packages than rather groups. I rather see the analogy with RPM Groups or .desktop categories. btw, just to make sure I got that right, can patterns be organized into a tree (i.e. do they have a hierarchy) ? e.g. Development/Database/Server
Patterns is about the ability to group packages for better overview and handling, mostly at the UI level. Its an abstraction level.
It's grouping... I wouldn't call that an "abstraction level" though :) An "abstraction", to me, would rather be to say "install texteditor" and you would get kate, emacs, vim or whatever ;)
However, I do agree that some kind of public 'pattern database' would be nice in order to find duplicates and overlaps.
Totally. I really see a risk of ending up with chaos here. To continue on my analogy with RPM groups and .desktop categories: if we didn't have a closed set of options to choose from (as defined in the SUSE Package Conventions), it would be havoc and the end-user KDE/GNOME menus wouldn't be very deep. At the very least, let's keep a pattern database (or rather, just a list) to try to reuse existing patterns if they match. ...
- 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.
Right.
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.
Makes sense. If patterns were hard dependencies, then we could achieve the same with packages (and Requires:).
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)
Yes please :)
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.
Mmmm... I don't agree ;)
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 ?
I don't see any package analogy here with the patterns. It's just that if you see it as an analogy to RPM Groups or .desktop categories, a package that's in my repository (or packman, or ...) should be able to merge into a pattern/group/category that's already present on the SUSE repository (or media), as in the example above.
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 ;-)
Ok, but I'd love to see it in smart ;))
Thanks for the feedback and information !
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\