Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* 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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* jdd [EMAIL PROTECTED] [Jul 23. 2006 14:57]: Pascal Bleser wrote: 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. this point deserve to be better seen. It's probably essential to have a closed set of patterns. We can (we must :-) discuss _before_ launching the system, but after that the modification of the pattern list should be very difficult. Think of patterns as of packages. By adding an external repo, extending the patterns list should be fairly easy. Of course, the same traps as with packages exist. One can't prevent name (or content) clashes. But you can minimize them by being as open as possible. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* Pascal Bleser [EMAIL PROTECTED] [Jul 23. 2006 12:46]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Klaus Kaempf wrote: * James Oakley [EMAIL PROTECTED] [Jul 12. 2006 16:44]: You could also use this to select tasks independently of the desktop environment. If you select Productivity/Chat and you have KDE and GNOME selected, you would get Konversation and XChat, but if you just have KDE, you would just get Konversation. Thats already possible with patterns. Could you give some more details about how it is or will be implemented ? With the 'freshens' and 'supplements' dependencies. 'Freshens' acts like a condition. If the frehens dependency is fulfilled (package/pattern being installed or to-be-installed), the supplements dependency is evaluated. So in the above example, Konversation would freshen the KDE pattern. In patterns, you can also define references to other patterns or packages to elect installation candidates ? Yes. But dependencies are only possible from the higher to an equal or lower abstraction level. So a pattern can only depend on another pattern or a package. But a package cannot depend on a pattern. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
-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
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Op dinsdag 25 juli 2006 18:49, schreef Klaus Kaempf: 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. Is it perhaps comparable to Categories in desktop files? /usr/share/applications # grep Categories *desktop | head MozillaFirefox.desktop:Categories=Application;Network;WebBrowser;X-Ximian-Main;X-Ximian-Toplevel;GTK Xkill.desktop:Categories=X-SuSE-DesktopUtility Xrefresh.desktop:Categories=X-SuSE-DesktopUtility YaST.desktop:Categories=SystemSetup;X-SuSE-Core-System base.desktop:Categories=Office;Database; calc.desktop:Categories=Office;Spreadsheet; draw.desktop:Categories=Graphics;VectorGraphics; -- Richard Bos Without a home the journey is endless - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Tue, Jul 25, 2006 at 07:19:55PM +0200, Pascal Bleser wrote: 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 As patterns can contain other patterns, I would say: yes. 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. Yes and no. e.g somebody makes a pattern 'Non SUSE multi-media' that includes all the MPlayer and mad libraries. e.g. when I now select MPlayer, I get all the extra codecs as well. So what the patern would have is e.g.: MPlayer, xmms-mad and k3b-mad (Don't shoot me if this is already included when installing MPlayer) At the very least, let's keep a pattern database (or rather, just a list) to try to reuse existing patterns if they match. A database would be extremely helpfull, especially if it were outside of SUSE. That way anybody can add their patterns. Would patterns also be able to contain information about installation sources? e.g. if I use a pattern, it will offer me (or add automagicaly) to add an extra installation source? -- The whole principle [of censorship] is wrong. It's like demanding that grown men live on skim milk because the baby can't have steak. -- Robert A. Heinlein in The Man Who Sold the Moon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* 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]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* houghi [EMAIL PROTECTED] [Jul 25. 2006 19:52]: Would patterns also be able to contain information about installation sources? No. Repositories offer patterns but not vice versa. e.g. if I use a pattern, it will offer me (or add automagicaly) to add an extra installation source? Well, a pattern could recommend (weak dependency) some 'non-existant' package which will be installed if a repo offering this package is known to the system. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Tue, Jul 25, 2006 at 09:10:05PM +0200, Klaus Kaempf wrote: * houghi [EMAIL PROTECTED] [Jul 25. 2006 19:52]: Would patterns also be able to contain information about installation sources? No. Repositories offer patterns but not vice versa. Pity. Oh well. We still need things we want to change after 10.2 comes out. :-D -- The whole principle [of censorship] is wrong. It's like demanding that grown men live on skim milk because the baby can't have steak. -- Robert A. Heinlein in The Man Who Sold the Moon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Oakley wrote: On Wednesday 12 July 2006 12:25 pm, Andreas Jaeger wrote: You got it ;-). It's really powerful and you could do such stuff. The question is do we want to do it this way? It makes it difficult to maintain them... It does introduce an extra step, at least. Whenever you create a package, you have to choose a group. You can think of this as just another kind of group. Also, when you split a package, you are consciously thinking about this grouping. PostgreSQL is obviously a database, and the postgresql-python subpackage is clearly meant for Python. More or less. When you split a package, you are thinking of dependencies and making certain features (and dependencies) optional when possible (see the miniSUSE thread about this) to avoid ending up with a 30GB base system ;) So basically, the best way to maintain this is to do it during package creation time. I'm thinking of the following scenarios: Let me just address a few things here regarding package creation time. Currently, we already have two categorizations: 1) the RPM Group: tag 2) the categories for .desktop files (menu entries for KDE and GNOME) Fortunately, there's a closed set of options, as defined in the SUSE Package Conventions: http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc.html RPM Groups are here: http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc_rpm_groups.html Desktop categories are here: http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc_desktop_menu.html#spc_dm_category_list As the set of options there is well-defined, it's usually quite easy to pick the right one. 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. Please always keep in mind that not all the RPMs are made by SUSE packagers, there are also quite a few community packagers out there (like me). We should also be able to use that patterns feature and put the packages we build into those. - The groups can be selected when the package is added to the buildservice. You are asked for name, summary, and description already. This is just one or two more pieces of metadata Build Service is just one of the options to provide RPMs for SUSE Linux. Many (critical, as far as most end-users are concerned) packages will never show up in there (just think of mad, lame, full-featured amarok, etc...). If the pattern a package is part of is stored in the Build Service metadata, then the whole list of .pat files can only be generated from the Build Service. The SUSE packagers also have their internal build system though (and I don't think it's planned to move the whole distribution to the Build Service). - 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. It is used in the Build Service where it is rather appropriate (and where other options would be more difficult to handle), but it's not a nice way of doing things. - If RPM is modified, new tags could be added, allowing the data to be placed directly in the header. With this, you could easily generate the selection files for an arbitrary collection of RPMs Forget modifying RPM with proprietary extensions. I really hope that will never, ever happen. What about other distributions that don't give a cent about those patterns ? Unless patterns become a native feature of RPM, RPM must not be modified to support that. Anyhow, that pattern infrastructure must be pluggable - i.e. every package must be able to define what pattern it is part of. I don't see why that information should be stored in spec files, that only makes things more complex (IMO) because you have to run over all the spec files to collect the information and create the .pat files. 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). The trick is just that for a given .pat file (e.g. development-database-server.pat), YaST2 (or libzypp or ZMD or whatever) must be capable of merging .pat files that have the same name across all the repositories it has in its list. 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 YaST2 must be
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Klaus Kaempf wrote: * James Oakley [EMAIL PROTECTED] [Jul 12. 2006 16:44]: You could also use this to select tasks independently of the desktop environment. If you select Productivity/Chat and you have KDE and GNOME selected, you would get Konversation and XChat, but if you just have KDE, you would just get Konversation. Thats already possible with patterns. Could you give some more details about how it is or will be implemented ? In patterns, you can also define references to other patterns or packages to elect installation candidates ? group name=Productivity group name=Chat package name=xchat depends group=Desktop/GNOME / /package package name=konversation depends group=Desktop/KDE / /package /group /group ? 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) iD8DBQFEw1Nir3NMWliFcXcRAtNvAJ9WTK4M//ZZ2XCafyl5dhjiBd6Q2wCeNW/v dqCEXejsrEUG0j21kZjrvdE= =8eIp -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
opensuse may better only support only one X Windows officially rather than both gnome and kde. as you do on commercial suse linux (SLES). support both (three, right? including fvwm2) is not productive. in my personal experience, gnome is more stable and using firefox is good choice than konqueror, many bug fixeds on firewall especially to meet compatible to IE. but still put kde as extra/option. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
tir, 18,.07.2006 kl. 23.05 -0700, skrev The Nice Spider: opensuse may better only support only one X Windows officially rather than both gnome and kde. as you do on commercial suse linux (SLES). support both (three, right? including fvwm2) is not productive. in my personal experience, gnome is more stable and using firefox is good choice than konqueror, many bug fixeds on firewall especially to meet compatible to IE. but still put kde as extra/option. Do you want some petrol to throw at that bonfire? ;-) Bjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, Jul 19, 2006 at 09:59:43AM +0200, Bjørn Lie wrote: Do you want some petrol to throw at that bonfire? ;-) LOL. It was indeed some bad trolling attempt. As long as WindowMaker is supported, I don't mind SUSE paying a bit attention to things like KDE and Gnome. I tried XFCE for several months, but found it lacking some bits here and there, especially in the easy of configuration. So if SUSE would help there, that would be great. That is however more XFCE development then it is SUSE development. -- houghi Please do not toppost http://houghi.org Please go to : http://tinyurl.com/aqe6y (Google site) and vote for 'Default quoting of previous message in replies' This was a broadcast from the netpolice. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Rajko M wrote: The problem is still in the packages that contain binaries. They are compiled with the broadest selection of options, ideally, the patterns could be defined _in build system_ so to give each user a perfectly fitted system (gentoo compiled by oepnSUSE). but is this possible? probably not. However, is we could define a limited amount of choices (compilation speaking), it could be possible to have then available. this add an other category to the ones I defined previously: compilation wise Jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Klaus Kaempf wrote: * jdd [EMAIL PROTECTED] [Jul 18. 2006 09:12]: Rajko M wrote: The problem is still in the packages that contain binaries. They are compiled with the broadest selection of options, ideally, the patterns could be defined _in build system_ so to give each user a perfectly fitted system (gentoo compiled by oepnSUSE). but is this possible? probably not. It might be possible. The openSUSE build service could give you this possibility. But its probably a long way to go ... Klaus I know Klaus, that is not easy as the number of options to sort out and document, is at least one order larger than number of packages. After sorting them it can be much smaller, but it is a huge task. It was just one more idea how to optimize the system and make it smaller and faster. -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
jdd [EMAIL PROTECTED] writes: [...] * this can be very powerfull, but for the very same reason must be very carefully examined. I wonder if it's not risky to 10.2 (don't do again the libzypp error), we must fine tune the definitions and scenarii before going to the implementation. That's why I start early and asked directly for feedback ;-). We *now* have enough time to do it and fine tune it... I just added only some example basic patterns so that installation is possible while we continue discussing. Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpxRJxFwaIYC.pgp Description: PGP signature
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Andreas Jaeger wrote: jdd [EMAIL PROTECTED] writes: [...] * this can be very powerfull, but for the very same reason must be very carefully examined. I wonder if it's not risky to 10.2 (don't do again the libzypp error), we must fine tune the definitions and scenarii before going to the implementation. That's why I start early and asked directly for feedback ;-). We *now* have enough time to do it and fine tune it... nice :-) so let's may be describe the problem differently. Given we must define a new package grouping system, what kind of categorisation is needed and a what time in the day to day openSUSE work. First, when will this system used: a1) first time install a2) update a3) system repair (previous install aborted abnormally-for example AC outage) a4) system cleaning (versus usability) a5) system cleaning (versus space left on disk) a6) test system (frequent install/uninstall - for example install _all_ the web editing system available) Then, package categorisation. we have currently at least (given all are rpm): b1) by great desktop system b1-1) kde b1-2) Gnome b1-3) XFCE b1-4) window manager (windowmaker, fvwm...) b1-5) console only b2) by goal (programming, word processing, multimedia...) b3) by system size/power b3-1) very low profile computer (up to PII) b3-2) first price computer (new) or old top notch one (from PII to p4, 256Mb ram) b3-3) gamer or top speed computer (p4, more than 1Gb ram...) b3-4) server - may be very strong, probably RAID, VPN, SCSI jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
jdd wrote: Andreas Jaeger wrote: jdd [EMAIL PROTECTED] writes: [...] * this can be very powerfull, but for the very same reason must be very carefully examined. I wonder if it's not risky to 10.2 (don't do again the libzypp error), we must fine tune the definitions and scenarii before going to the implementation. That's why I start early and asked directly for feedback ;-). We *now* have enough time to do it and fine tune it... nice :-) so let's may be describe the problem differently. Given we must define a new package grouping system, what kind of categorisation is needed and a what time in the day to day openSUSE work. First, when will this system used: a1) first time install a2) update a3) system repair (previous install aborted abnormally-for example AC outage) a4) system cleaning (versus usability) a5) system cleaning (versus space left on disk) a6) test system (frequent install/uninstall - for example install _all_ the web editing system available) Then, package categorisation. we have currently at least (given all are rpm): b1) by great desktop system b1-1) kde b1-2) Gnome b1-3) XFCE b1-4) window manager (windowmaker, fvwm...) b1-5) console only b2) by goal (programming, word processing, multimedia...) b3) by system size/power b3-1) very low profile computer (up to PII) b3-2) first price computer (new) or old top notch one (from PII to p4, 256Mb ram) b3-3) gamer or top speed computer (p4, more than 1Gb ram...) b3-4) server - may be very strong, probably RAID, VPN, SCSI jdd Let me jump in with one fundamental question. The patterns can be arranged in different ways giving almost unlimited freedom to form final result, customized system. The problem is still in the packages that contain binaries. They are compiled with the broadest selection of options, so they can fit in a as many configurations as possible. That gives a lot of unused code and dependencies in custom installation. Having some experience with Gentoo, where all was compiled from scratch I can appreciate fast execution of such binaries. When comes to updates or expansion that requires new compile options, than it is another story. Is it possible to create patterns for special purposes (advanced users) that will combine both approaches, some base that is precompiled and the most used applications and libraries in such system to be customized and then compiled. Basic idea is to allow experienced users to see in advance what functionality they get, how much in code size it will cost, and them make decision what to do. How complicated is to include compilation as one of options in a system creation? How long it may take to document sufficiently compilation options? Is it viable at this point to consider compilation options as dependency control? The last will allow to shrink the system substantially, as user will be able to select functionality, not only package. -- Regards, Rajko. Visit http://en.opensuse.org/MiniSUSE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Fredag 14 juli 2006 19:50 skrev Boyd Lynn Gerber: Saving and retreiving selections is close to the top of my list of things missing. Since we're on the subject - and there appears to be a lot of development on YaST going on. I've been meaning to file a bugzilla-enhancement about adding an update filter. Simply a filter that shows only packages where a newer version is available - meaning all the blue packages. One of the critiques I often hear about YaST is that updating is too much of a chore. This way you could just select update filter right click in list update all in this list - if that's what you want - but you can also easily select the updates that you do and don't want. Just an idea. I'll probably get around to filing this and a few other enhancement suggestions shortly. Martin / cb400f - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Sat, Jul 15, 2006 at 01:25:51PM +0200, Martin Schlander wrote: One of the critiques I often hear about YaST is that updating is too much of a chore. I think it is a generic SUSE issue, not just a YaST problem. Other distributions are able to do a version update fairly easy. With SUSE the result can be somewhat different, especially when updating a more non-standard SUSE machine. Now the standard advice is to do a new installation or at least be prepared to do a new installation if things go bad. -- houghi Please do not topposthttp://houghi.org Beware of he who would deny you access to information, for in his heart he dreams himself your master. Commissioner Pravin Lal: U.N. Declaration of Rights - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
houghi wrote: Now the standard advice is to do a new installation or at least be prepared to do a new installation if things go bad. I see a lot of upgrade problems on my lug forum, with apt-distupgrade :-) (specially from stable to unstable :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* houghi [EMAIL PROTECTED] [Jul 12. 2006 16:13]: 3) General notes. As far as I understand, I could just add OOo and then during installation will install all dependencies? Yes. What happens when I then want to deinstall OOo? Will it recognise the extra things it installed, or will that still be left behind? For (rpm) packages, just the package will be removed. For patterns, we're looking for proposals on how to do it. We would like to handle patterns as 'groups' so when you remove a pattern all members of that group are removed as well. But such semantics might not be intuitive. Consider the following case: You're using (maybe unwittingly) a specific functionality/application on a regular basis. Over time, your systems gets crowded and you decide to clean it up a bit. You do this by removing 'unneeded' patterns. Afterwards your above mentioned application is gone and you might not know to which pattern it belonged (or which package it was). Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* James Oakley [EMAIL PROTECTED] [Jul 12. 2006 16:44]: You could also use this to select tasks independently of the desktop environment. If you select Productivity/Chat and you have KDE and GNOME selected, you would get Konversation and XChat, but if you just have KDE, you would just get Konversation. Thats already possible with patterns. I think that could be very powerful. :-) Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* jdd [EMAIL PROTECTED] [Jul 12. 2006 21:04]: Klaus Kaempf wrote: Packages listed in selection are all required weak. Removal of such a package does not warn you about invalidating a selection. are you sure of that? Yes. ;-) I just installed a 10.0 to make tests for minisuse, I browsed all installed packages for minimal install and removed a lot of (small) packages really unusefull. At the end I was faced with a screen giving a list of needed packages with no possibility to don't install them, some as important as alsa, checkmedia or gnome-filesystem (on a terminal only system!). Thats a bug in the 10.0 implementation. It goes through all to-be-installed selections and installs their packages. You have to set the packages to 'taboo' to prevent this. In fact I see just now that I can uninstall them after install... Thats what I meant. And uninstalling all packages of a selection leaves the selection installed ... Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* houghi [EMAIL PROTECTED] [Jul 14. 2006 11:53]: On Fri, Jul 14, 2006 at 11:26:41AM +0200, Klaus Kaempf wrote: You're using (maybe unwittingly) a specific functionality/application on a regular basis. Over time, your systems gets crowded and you decide to clean it up a bit. You do this by removing 'unneeded' patterns. Afterwards your above mentioned application is gone and you might not know to which pattern it belonged (or which package it was). Won't there still be th possability to install (and remove) individual packages? Of course there will. So when I remove unneeded patters and then decide I still want package X, I should be able to just install package X with 'search'. Sure. But you have to know the X. If you just deal with patterns, the X might not be obvious. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Klaus Kaempf wrote: Thats a bug in the 10.0 implementation. right now I use 10.0 because I can't save the selection with 10.1 jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Hi, Andreas Jaeger schrieb: * Patterns define a functionality the system should have. This is indeed a currently missing feature. But it would be nice to have a more abstract definition of functionality - for example, a pattern should be able to say the user needs a PDF viewer and not the user needs xpdf. Currently, when selecting GNOME during installation and using the Add-On product, I get three PDF viewers: xpdf from the base X selection, evince from the GNOME selection and acroread from the Add-On product. Packages could provide a virtual symbol describing their functionality, every desktop-related pattern should require this virtual symbol and the package manager should be able to decide which one of the available alternatives matches the selected pattern in the best way. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* Andreas Hanke [EMAIL PROTECTED] [Jul 14. 2006 17:13]: Hi, Andreas Jaeger schrieb: * Patterns define a functionality the system should have. This is indeed a currently missing feature. But it would be nice to have a more abstract definition of functionality - for example, a pattern should be able to say the user needs a PDF viewer and not the user needs xpdf. Agreed. pdf viewer is the pattern, xpdf is the package. Patterns are meant to be an abstraction from packages. So having a xpdf pattern is certainly wrong, pdf viewer is the right pattern name. Currently, when selecting GNOME during installation and using the Add-On product, I get three PDF viewers: xpdf from the base X selection, evince from the GNOME selection and acroread from the Add-On product. Parts of that are already implemented and working. Packages could provide a virtual symbol describing their functionality, every desktop-related pattern should require this virtual symbol and the package manager should be able to decide which one of the available alternatives matches the selected pattern in the best way. Thats probably too much work for package maintainers. And for most functionalities, there is typically a single 'preferred' implementation (== package) and possible alternative implementation. For the functionality mail-transfer-agent, 'postfix' is (currently) the preferred and 'sendmail', 'qmail', etc. are the alternative implementations. But the package-pattern relation is expressed in the pattern, not in the package. For user environments, things are a bit more complicated. The functionality mailer might be 'mutt' for the console, 'kmail' for KDE, and 'evolution' for GNOME. The 'mail program' pattern depends on the choosen user environment and must be calculated. The current pattern implementation supports this already. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Boyd Lynn Gerber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Klaus Kaempf wrote: Thats a bug in the 10.0 implementation. right now I use 10.0 because I can't save the selection with 10.1 Saving and retreiving selections is close to the top of my list of things missing. Top is the package management then this feature. it's not very important for me, for the moment I just test some ideas I really like the new Package Group with patterns. I find it to be really exciting. I have two meanings on this one: * It's a very good idea, it will solve most of my problems choosing packages for minisuse (busybox is included by default in suse instal, should be nice to remove all the stuff it can replace :-) - just an example. * this can be very powerfull, but for the very same reason must be very carefully examined. I wonder if it's not risky to 10.2 (don't do again the libzypp error), we must fine tune the definitions and scenarii before going to the implementation. jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Dňa St 12. Júl 2006 17:17 Klaus Kaempf napísal: * Kenneth Schneider [EMAIL PROTECTED] [Jul 12. 2006 16:17]: I don't mean don't install needed packages, just show where they belong. GNOME packages do not need to be seen in the KDE section is all I am saying even if there are some sort of cross dependencies. Thats a problem of our current selections, they're too fat. There should be some kind of core desktop libs pattern which lists all library packages needed by kde and gnome. And, the current selections were unable to do dependency resolution, so a selection had to contain all its requires as well. But don't think you will not get any GNOME libraries for KDE. This is the price for integration and can be solved only on the responsible packages. Stano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, Jul 12, 2006 at 11:18:00AM +0200, Andreas Jaeger wrote: This misses some of the selections and introduces new ones. This is really a first step for discussion. I would like you to come up with better high-level proposals! Let's not discuss we need this pattern as well - but let's discuss and agree on the general framework and then let's discuss adding further patterns. A realy nice idea. How does it work? Does it still use the *.sel things, or is it something completely new? I am asking because with makeSUSEdvd if you add your own RPMs, a makeSUSEdvd.sel is made, making it possible to select during installation. So what are the technical differences between what we have and what we will get? Will adding one cause trouble over the other? Btw. we have a nice way of adding new, third-party patterns: Basically all you need is to have a lightweight add-on product that only has patterns, but no RPMs. So one could create his or her favourite package collections and make them available as an add-on source. Every repository can add patterns. And is there information on that as well? Btw. I've put the above on the wiki at: http://en.opensuse.org/Patterns Thanks. The idea is nice, yet it needs a lot of extra info to look at. -- houghi Please to not toppost http://houghi.org You tried, and you failed, so the lesson is, never try. - Homer J. Simpson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Andreas Jaeger wrote: Let's not discuss we need this pattern as well - but let's discuss and agree on the general framework this seems very promising and then let's discuss adding further patterns. we should add a role hardware. We should be able to build install cd/dvd on the role base (for example, desktop computers don't need pcmcia, old box don't need sata, some boxes are all scsi or (mostly) no scsi at all) patterns should be more refined. There is a lot of things completely unusefull in the Base packages (for some uses); So we should have * a very minimal set. may be only static kernel, skel. only text console access, neither yast - ideally floppy boot :-) and then a Yast pattern, a X pattern, a sax pattern (may be a SUSE pattern with yast and sax :-) the main difficulty I see is rewriting the rpm dependencies (devs tend to add dependencies to be sure the product run anywhere), but may be the build service can adress this? basically, If I understand well, anybody could go to the build service, load a form, answer detailed questions about his goals and his hardware and use net install. on this respect, it would be very interesting to have an utility (boot floppy or cd, like memtest) that do a hardware check and report; The same thing that is done at install time, but without the installer, just check. May be say your computer is ready for Linux, or this part can be a problem. I know this is what is done mostly by the installer, but I think it should be good to have it separated. Any body is anxious when putting an install cd on a reader (will this erase my computer?), a diagnostic cd is not so frightening :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, Jul 12, 2006 at 11:55:10AM +0200, Andreas Jaeger wrote: So what are the technical differences between what we have and what we will get? Will adding one cause trouble over the other? You cannot mix selections and patterns in a product - and we will remove all selection support now. AAARRGG. Needing to re-write makeSUSEdvd again. ;-) It looks like you do all this on purpose, just to anoy me. :-D I asume that `create_package_descr` will be either completely re-written or replaced by something else? If so, would it be possible to see that? On another level, if I place *.pat files in the directory together with *.sel files, the old system does not handle them, so there should be no problem. If there are *.sel in a newer version (10.2 Alpha3) then it won't do anything with that, I asume, because it does not know what to do with it. So also no problem there (I hope) The reason for that would be using the same makeSUSEdvd for all versions. An extra if-then-else to see what is needed and I am done. :-) And is there information on that as well? Not yet AFAIK. :-( -- houghi Please to not toppost http://houghi.org You tried, and you failed, so the lesson is, never try. - Homer J. Simpson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Glenn Holmer [EMAIL PROTECTED] writes: On Wednesday 12 July 2006 04:18, Andreas Jaeger wrote: * Patterns can be grouped into roles, like Development or Desktop. * Patterns can require other patterns Will there be a way to have alternate choices, e.g. if you select Database Server you can choose between MySQL and Postgres, or either if you select Java Development you can choose between NetBeans and Eclipse? It really depends how fine granular we make the patterns. We could have a * MySQL Database Server * Postgres Database Server * Java Development with NetBeans * Java Development with Eclipse ... And then end with 1000 different patterns ;-) That's why I'm asking here on your ideas - and on complete proposals. Will there be a way to save your selections to e.g. memory stick for doing multiple installs? (do the selection on the first machine, then read it in for the rest of the machines)? Something to discuss separately, interesting idea, I'll pass it on, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpwI0hg6hjqN.pgp Description: PGP signature
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, 2006-07-12 at 11:18 +0200, Andreas Jaeger wrote: Currently in SUSE Linux 10.1 (and earlier releases) we use selections in YaST to group software and easily enable installation of related software. Our developers have enhanced the concept of selections and call it patterns. snip Also why not eliminate the duplication of packages in the patterns. When looking at and selecting KDE packages I should _not_ be presented with GNOME packages for selection as well. I have not ever understood why a package shows up in numerous places. As a first step for discussion I propose these roles and patterns: * Graphical Environments - GNOME Desktop Environment - KDE Desktop Environment - X Window System (with fvwm2) * Base Technologies - Base System (always installed) - AppArmor - Xen Virtual Machine Host Server * Development - C/C++ Compiler and Tools - GNOME Development - KDE/QT3 Development - Qt 4 Development - Linux Kernel Development - Version Control Systems * Primary Functions - File Server - Print Server - Mail and News Server - Web and LAMP Server - Internet Gateway - DHCP and DNS Server - Directory (LDAP) Server This misses some of the selections and introduces new ones. This is really a first step for discussion. I would like you to come up with better high-level proposals! Let's not discuss we need this pattern as well - but let's discuss and agree on the general framework and then let's discuss adding further patterns. Btw. we have a nice way of adding new, third-party patterns: Basically all you need is to have a lightweight add-on product that only has patterns, but no RPMs. So one could create his or her favourite package collections and make them available as an add-on source. Every repository can add patterns. Btw. I've put the above on the wiki at: http://en.opensuse.org/Patterns Andreas -- Ken Schneider - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, 2006-07-12 at 11:43 +0200, jdd wrote: Andreas Jaeger wrote: Let's not discuss we need this pattern as well - but let's discuss and agree on the general framework this seems very promising and then let's discuss adding further patterns. on this respect, it would be very interesting to have an utility (boot floppy or cd, like memtest) that do a hardware check and report; The same thing that is done at install time, but without the installer, just check. May be say your computer is ready for Linux, or this part can be a problem. Very good idea, but have it as a separate download so people can check their system before they download the larger images ( CD's/DVD images) or purchase the package at retail. This way they can make an informed decision before hand and not come back upset because they didn't know something would not work. -- Ken Schneider - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* houghi [EMAIL PROTECTED] [Jul 12. 2006 12:35]: On Wed, Jul 12, 2006 at 11:55:10AM +0200, Andreas Jaeger wrote: So what are the technical differences between what we have and what we will get? Will adding one cause trouble over the other? You cannot mix selections and patterns in a product - and we will remove all selection support now. AAARRGG. Needing to re-write makeSUSEdvd again. ;-) It looks like you do all this on purpose, just to anoy me. :-D Yep. ;-) I asume that `create_package_descr` will be either completely re-written or replaced by something else? If so, would it be possible to see that? No, its just replacing .sel by .pat. All other files stay untouched. On another level, if I place *.pat files in the directory together with *.sel files, the old system does not handle them, so there should be no problem. If there are *.sel in a newer version (10.2 Alpha3) then it won't do anything with that, I asume, because it does not know what to do with it. So also no problem there (I hope) Not quite. SL10.1 libzypp recognizes both and will get confused if it finds .sel and .pat files. We probably will remove .sel support from libzypp in SL10.2 rsn. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* jdd [EMAIL PROTECTED] [Jul 12. 2006 11:43]: patterns should be more refined. There is a lot of things completely unusefull in the Base packages (for some uses); So we should have * a very minimal set. may be only static kernel, skel. only text console access, neither yast - ideally floppy boot :-) and then a Yast pattern, a X pattern, a sax pattern (may be a SUSE pattern with yast and sax :-) Yes, thats exactly the direction we want to go with patterns. on this respect, it would be very interesting to have an utility (boot floppy or cd, like memtest) that do a hardware check and report; The same thing that is done at install time, but without the installer, just check. May be say your computer is ready for Linux, or this part can be a problem. We tried something like that before but never really found time to complete it. It should upload the output of hwinfo to some webserver which compares detected hardware devices against entries in a database. It could then report the 'support status'. A bootable CD which writes its findings to USB stick (or even a bootable USB image if the BIOS supports it) could be pretty nice. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Kenneth Schneider wrote: Also why not eliminate the duplication of packages in the patterns. When looking at and selecting KDE packages I should _not_ be presented with GNOME packages for selection as well. think also of _negative_ instructions. I think of no Kde library or no gnome library a problem with Linux is the enormous amount of libraries that one can install sometimes for nearly nothing :-) -wants a card game, have kde :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* Glenn Holmer [EMAIL PROTECTED] [Jul 12. 2006 12:54]: On Wednesday 12 July 2006 04:18, Andreas Jaeger wrote: * Patterns can be grouped into roles, like Development or Desktop. * Patterns can require other patterns Will there be a way to have alternate choices, e.g. if you select Database Server you can choose between MySQL and Postgres, or either if you select Java Development you can choose between NetBeans and Eclipse? Yes, this could be done. However, depending on whom you ask, people will love or hate such questions. The pattern mechanism allows you to define a Database Server pattern which requires a database_engine. MySQL and Postgres could both provide database_engine and serve to fulfill this requirement. By default, one of these will be preselected but the user can de-select one for the other. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* jdd [EMAIL PROTECTED] [Jul 12. 2006 14:36]: think also of _negative_ instructions. I think of no Kde library or no gnome library Use the conflicts depedency for this. I.e. a No kde libs pattern which conflicts with all kde libraries. Don't know how useful such a system would be ... Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Klaus Kaempf wrote: (or even a bootable USB image if the BIOS supports it) could be pretty nice. an usb bootable suse is anyway a very needed thing, now than 2Gb usb sticks are cheap :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Kenneth Schneider [EMAIL PROTECTED] writes: Also why not eliminate the duplication of packages in the patterns. When looking at and selecting KDE packages I should _not_ be presented with GNOME packages for selection as well. I have not ever understood why a package shows up in numerous places. We currently have packages and dependicies in the selections, we plan to have only packages in it - and a package in the KDE selection might then have as dependency some GNOME packages/libraries but we'll not listen them explictely, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpSVSAtARr1N.pgp Description: PGP signature
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, Jul 12, 2006 at 02:29:23PM +0200, Klaus Kaempf wrote: It looks like you do all this on purpose, just to anoy me. :-D Yep. ;-) I thought so. ;-) Not quite. SL10.1 libzypp recognizes both and will get confused if it finds .sel and .pat files. We probably will remove .sel support from libzypp in SL10.2 rsn. OK. I will post my answer here, even though it actually is a reply to several postings in this thread. 1) On different .sel or .pat on one iso (in one directory) For me it means checking if there are .sel or .pat files and then use the correct way to install it. Will create_package_descr still be able to make .sel files, or will it be completely removed? If removed, a new program might be more interesting. A forked version if you like. This so coninuity is garanteed. I would prefere the program to be able to do both with using an option for the newer package type. 2) On the ability to save Something that realy can become interesting, as you can then save and even more imortandly share it with others. That way I can make a setup that I think is great, put it on my openSUSE.org space and let other people enjoy it. So it would be great if such an option can be read from somewhere else either during installation or later. 3) General notes. As far as I understand, I could just add OOo and then during installation will install all dependencies? What happens when I then want to deinstall OOo? Will it recognise the extra things it installed, or will that still be left behind? What about things I installed with rpm -Uvh? -- houghi Please to not toppost http://houghi.org You tried, and you failed, so the lesson is, never try. - Homer J. Simpson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, 2006-07-12 at 14:36 +0200, jdd wrote: Kenneth Schneider wrote: Also why not eliminate the duplication of packages in the patterns. When looking at and selecting KDE packages I should _not_ be presented with GNOME packages for selection as well. think also of _negative_ instructions. I think of no Kde library or no gnome library a problem with Linux is the enormous amount of libraries that one can install sometimes for nearly nothing :-) -wants a card game, have kde :-) jdd I don't mean don't install needed packages, just show where they belong. GNOME packages do not need to be seen in the KDE section is all I am saying even if there are some sort of cross dependencies. Ken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wednesday 12 July 2006 9:41 am, Klaus Kaempf wrote: * Glenn Holmer [EMAIL PROTECTED] [Jul 12. 2006 12:54]: On Wednesday 12 July 2006 04:18, Andreas Jaeger wrote: * Patterns can be grouped into roles, like Development or Desktop. * Patterns can require other patterns Will there be a way to have alternate choices, e.g. if you select Database Server you can choose between MySQL and Postgres, or either if you select Java Development you can choose between NetBeans and Eclipse? Yes, this could be done. However, depending on whom you ask, people will love or hate such questions. Actually, I think this can be used to take some of the drudgery out of the package selections. I end up going through all of groups to make sure that I get all of the packages I need, but if a pattern can select packages based on other selected patterns, I could spend far less time on it. If I select Database/PostgreSQL alone, it will install the server and client, but if I also have Development/C and C++ and Development/Python selected, postgresql-devel and postgresql-python will also be installed. Similarly, if I select Desktop Environments/KDE it will install a basic KDE system, but if I also have Hardware/TV Capture it will also install kwintv. You could also use this to select tasks independently of the desktop environment. If you select Productivity/Chat and you have KDE and GNOME selected, you would get Konversation and XChat, but if you just have KDE, you would just get Konversation. I think that could be very powerful. -- James Oakley [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* Kenneth Schneider [EMAIL PROTECTED] [Jul 12. 2006 16:17]: I don't mean don't install needed packages, just show where they belong. GNOME packages do not need to be seen in the KDE section is all I am saying even if there are some sort of cross dependencies. Thats a problem of our current selections, they're too fat. There should be some kind of core desktop libs pattern which lists all library packages needed by kde and gnome. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
James Oakley [EMAIL PROTECTED] writes: On Wednesday 12 July 2006 9:41 am, Klaus Kaempf wrote: * Glenn Holmer [EMAIL PROTECTED] [Jul 12. 2006 12:54]: On Wednesday 12 July 2006 04:18, Andreas Jaeger wrote: * Patterns can be grouped into roles, like Development or Desktop. * Patterns can require other patterns Will there be a way to have alternate choices, e.g. if you select Database Server you can choose between MySQL and Postgres, or either if you select Java Development you can choose between NetBeans and Eclipse? Yes, this could be done. However, depending on whom you ask, people will love or hate such questions. Actually, I think this can be used to take some of the drudgery out of the package selections. I end up going through all of groups to make sure that I get all of the packages I need, but if a pattern can select packages based on other selected patterns, I could spend far less time on it. If I select Database/PostgreSQL alone, it will install the server and client, but if I also have Development/C and C++ and Development/Python selected, postgresql-devel and postgresql-python will also be installed. Similarly, if I select Desktop Environments/KDE it will install a basic KDE system, but if I also have Hardware/TV Capture it will also install kwintv. You could also use this to select tasks independently of the desktop environment. If you select Productivity/Chat and you have KDE and GNOME selected, you would get Konversation and XChat, but if you just have KDE, you would just get Konversation. I think that could be very powerful. You got it ;-). It's really powerful and you could do such stuff. The question is do we want to do it this way? It makes it difficult to maintain them... If people like this, let's make a full proposal... Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpOj4Mum6SAU.pgp Description: PGP signature
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As a first step for discussion I propose these roles and patterns: * Graphical Environments - GNOME Desktop Environment - KDE Desktop Environment - X Window System (with fvwm2) * Base Technologies - Base System (always installed) - AppArmor - Xen Virtual Machine Host Server * Development - C/C++ Compiler and Tools - GNOME Development - KDE/QT3 Development - Qt 4 Development - Linux Kernel Development - Version Control Systems * Primary Functions - File Server - Print Server - Mail and News Server - Web and LAMP Server - Internet Gateway - DHCP and DNS Server I think the two above should be split. I personally never use DHCP but do a lot with DNS. In fact I remove DHCP from most if not all my systems. This would force me to have on my systems DHCP. In the DNS Server would/could include SPF. SPF and DSN Server would for my uses be a better choice. - -- Boyd Gerber [EMAIL PROTECTED] ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFEtRsIVtBjDid73eYRAhyGAJ0XEoa8PxQAsM2Blljdl1bvJRSlAACfV+8o SO+AUM1C6P5Jnp1moEGHvP8= =t+e0 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, Jul 12, 2006 at 09:53:40AM -0600, Boyd Lynn Gerber wrote: I think the two above should be split. I personally never use DHCP but do a lot with DNS. In fact I remove DHCP from most if not all my systems. This would force me to have on my systems DHCP. In the DNS Server would/could include SPF. SPF and DSN Server would for my uses be a better choice. I asume it still will be possible to install and/or remove individual packages. I also think it will be impossible to have a good situation for each and every person, because that would mean having an almost limitless amount of combinations. Having each and every service seperated might not be wanted, because of complexity it will bring. If the selection happens in the same way as it happens now, deselecting DHCP should not e a real problem. I can imagine that most people who use a DHCP server will also use a DNS server and perhaps also the other way around. -- houghi Please to not toppost http://houghi.org You tried, and you failed, so the lesson is, never try. - Homer J. Simpson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* houghi [EMAIL PROTECTED] [Jul 12. 2006 18:44]: I asume it still will be possible to install and/or remove individual packages. Well ... yes, of course. But remember that the main difference to selections is the possibility to have hard (real) requirements. So if you have a pattern X installed which requires package P, removal of P will trigger a conflict with the requirement from X. Packages listed in selection are all required weak. Removal of such a package does not warn you about invalidating a selection. Having each and every service seperated might not be wanted, because of complexity it will bring. Define one pattern DNS Server and one DHCP Server and one DNS DHCP Server requiring both. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, Jul 12, 2006 at 08:04:33PM +0200, Klaus Kaempf wrote: Having each and every service seperated might not be wanted, because of complexity it will bring. Define one pattern DNS Server and one DHCP Server and one DNS DHCP Server requiring both. Won't that result in too many choices? Too many choices might confuse people more then it helps them. With these two you already have three. Add e.g. Apache, postfix, MySQL and ssh and you have a multitude of choices. e.g. every single one, every combination of two, of three, four five and six. I would thing that on one side that abount of choices is good, on the other side it might become confusing and this is just for a few services. Or am I missing something? -- houghi Please to not toppost http://houghi.org You tried, and you failed, so the lesson is, never try. - Homer J. Simpson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Klaus Kaempf wrote: Packages listed in selection are all required weak. Removal of such a package does not warn you about invalidating a selection. are you sure of that? I just installed a 10.0 to make tests for minisuse, I browsed all installed packages for minimal install and removed a lot of (small) packages really unusefull. At the end I was faced with a screen giving a list of needed packages with no possibility to don't install them, some as important as alsa, checkmedia or gnome-filesystem (on a terminal only system!). In fact I see just now that I can uninstall them after install... jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 12, 2006 at 08:04:33PM +0200, Klaus Kaempf wrote: Having each and every service seperated might not be wanted, because of complexity it will bring. Define one pattern DNS Server and one DHCP Server and one DNS DHCP Server requiring both. Won't that result in too many choices? Too many choices might confuse people more then it helps them. With these two you already have three. Add e.g. Apache, postfix, MySQL and ssh and you have a multitude of choices. e.g. every single one, every combination of two, of three, four five and six. I would thing that on one side that abount of choices is good, on the other side it might become confusing and this is just for a few services. Or am I missing something? I think that what needs to happen is have at the top most used packages but lower dependentcies being the lowest posible grouping to statisfy requirements. DNS DHCP Server DNS Server DHCP Server So if the top is checked it requires all, but it only DNS Server is check a partial is somehow reflected in the top level but only the DNS Server is the requirement marked. Also All Server LAMP Server Apache Server MySQL Server P Server PHP Perl Python LAPP Server Apache Server Postress Server P Server PHP Perl Python So both the above have a P Server Reguirement, Apache Requirement, but the database is a seperate requirement that may be filled by what ever choice of database/s that are wanted. I hope this explains the idea I am tring to suggest. - -- Boyd Gerber [EMAIL PROTECTED] ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFEtU76VtBjDid73eYRAv7yAJ90cq+urwfevftT/9XTZVFA7m1PlgCgjCH6 /fl9h0iGeQgreDzfGDwMPUg= =SQrQ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Hi On Wednesday 12 July 2006 13:08, Andreas Jaeger wrote (shortened): I asume that `create_package_descr` will be either completely re-written or replaced by something else? If so, would it be possible to see that? Lars? Yes: completely re-written. I'm sorry, but I can give no final release date for the new script. Currently we're changing very much and try to integrate things we've outsourced to helper scripts bevore (with the intention to make the CD creation process a little bit faster). In the end we can hopefully create a new package containing scripts for creating installation and update sources, CDs and so on . Currently you can find the latest official script in the rpm autoyast-utils. But this package creation is at the end of a very long todo list... :-( Lars - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wednesday 12 July 2006 16:13, houghi wrote (shortened): Will create_package_descr still be able to make .sel files, or will it be completely removed? create_package_descr has never created .sel or .pat files. create_package_descr is only responsible for the creation of the /suse/setup/descr/packages* files. As far as I understand, I could just add OOo and then during installation will install all dependencies? Yes. Thats one thing the resolver does (hopefully ;-). What happens when I then want to deinstall OOo? Will it recognise the extra things it installed, or will that still be left behind? Should be nearly the same as rpm -e OOo... What about things I installed with rpm -Uvh? No problem with that - it's the same behavior as bevore. This has nothing to do with patterns ;-) Lars - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, Jul 12, 2006 at 01:35:17PM -0600, Boyd Lynn Gerber wrote: So both the above have a P Server Reguirement, Apache Requirement, but the database is a seperate requirement that may be filled by what ever choice of database/s that are wanted. I hope this explains the idea I am tring to suggest. Ah, ok. Much clearer, yes. -- houghi Please to not toppost http://houghi.org You tried, and you failed, so the lesson is, never try. - Homer J. Simpson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Wed, Jul 12, 2006 at 11:16:15PM +0200, Lars Rupp wrote: On Wednesday 12 July 2006 16:13, houghi wrote (shortened): Will create_package_descr still be able to make .sel files, or will it be completely removed? create_package_descr has never created .sel or .pat files. create_package_descr is only responsible for the creation of the /suse/setup/descr/packages* files. OK, Must be the heat in my studio, or something. I hope to see something before 10.2 Alpha 3 comes out. No need for it to be in RPM. That would make asking questions a lot easier. -- houghi Please to not toppost http://houghi.org You tried, and you failed, so the lesson is, never try. - Homer J. Simpson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
