-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaus Kaempf wrote: > * Pascal Bleser <[EMAIL PROTECTED]> [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/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFExlK6r3NMWliFcXcRAgpeAJ0ZBdYosbps6PYGFNLVFlCC/4M3jgCbBcov wSCs3bJ1qrF1S98kWjdIVXQ= =E+i3 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
