* Pascal Bleser <[EMAIL PROTECTED]> [Jul 25. 2006 19:20]: > > 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.
Patterns is what you make of it ;-) Their basics is dependencies, just like packages have. They support hard (requires) and weak (recommends, suggests) dependencies to patterns or(!) packages. Reverse dependencies (supplements == install me if dependency matches) are also possible. > > I rather see the analogy with RPM Groups or .desktop categories. You can organize patterns like this but to me their real value is in expressing functionalities as building blocks to a complete system. > > 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 You can express hierachies via dependencies. But the tree you're thinking of is probably better expressed via Keywords and some UI logic. > > > 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 ;) If a pattern 'texteditor' exists, thats exactly what will happen. Ideally, there is one preferred implementation of the functionality 'texteditor'. For a KDE Desktop its probably kate. But this pattern can also list other editors. It could be like 'customers who bought this also bought that' in Amazon. Abstraction to me means mostly getting away from the package flood. If I look for an office suite on the package level, I probably end up with at least 4 OpenOffice packages (OpenOffice_org, OpenOffice_org-Quickstarter, OpenOffice_org-kde and a translation package). On the pattern level, I would only see one entry. > > > 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. I agree when looking at keywords as mentioned above. For patterns themselves, a 'creative chaos' might be quite helpful in the beginning. Useful patterns will emerge from this just like distributions emerge from the 'package chaos' which exists in the open source world. [...] > > > 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. YaST already gives you the 'rpm group' view. Is it helpful ? How can we improve here ? Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
