[opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
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. What are patterns? * patterns include a list of software packages to install * the list of software packages contains packages that are - required (must-have) - recommended (should-have) - suggested (may-have) * Patterns define a functionality the system should have. They do this by either directly naming required packages or by grouping of sub-patterns, or a combination thereof. This partitions the huge list of installed rpms into building blocks which can be combined (almost) at will. By listing each and every rpm in a (ideally: exactly one) pattern, this related rpms to functionalities. This in turn finally gives an answer to the often asked question: "Why is this package installed ?" * in the future we like to drive workflow with patterns as well, e.g. if you select the (imaginary) LDAP server pattern, the LDAP configuration workflow will be called during installation. * Patterns can be grouped into roles, like "Development" or "Desktop". * Patterns can require other patterns They have the same set of (possible) dependencies as packages have. So they can also obsolete (replace) or conflict other patterns. Or have language dependencies, etc. * Add-on products can have additional patterns * Patterns can be differentiated between top-level/user-visible and internal/non-user-visible patterns (a pattern might require others that are not visible) - these are implementation details of the patterns. Directly after 10.2 Alpha2, I'd like to switch to patterns. Instead of simply rewriting the existing selections to patterns, I would like to start basically from scratch and define with you which patterns we should have. Currently we have the following selections: * Graphical Base System * KDE Desktop Environment * All of KDE * GNOME System * Help and Support Documentation * Office Applications * Games * Multimedia * Voice over IP * Xen Virtualization * Simple Web Server with Apache2 * LDAP Server and Tools * Network and Server * Laptop * Mobile Computing * C/C++ Compiler and Tools * Kernel Development * KDE Development * GNOME Development * Tcl/Tk Development System * Java * Experienced User * LaTeX, SGML and XML * Fonts * Mono/CLR * Non-Open Source Packages 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 -- Andreas Jaeger, aj@suse.de, 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
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
houghi <houghi@houghi.org> writes:
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.
It uses *.pat files ;-).
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.
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?
Not yet AFAIK.
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.
Andreas -- Andreas Jaeger, aj@suse.de, 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
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.
AAARRRRRRGGGGGG. 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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
houghi <houghi@houghi.org> writes:
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.
AAARRRRRRGGGGGG. 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?
Lars?
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)
Correct.
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. :-)
Andreas -- Andreas Jaeger, aj@suse.de, 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Rupp wrote:
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).
huh? guys, you need some more planning+tracking ;)))
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... :-(
Please also keep us 3rd party packagers in mind when doing all that. Creating repositories for yast2 is a pain as of now (luckily, createrepo is very easy to use but doesn't do the repo signing either). Really, the repository signing thing in 10.1 must be the worst thing you did to us: no communication or beforehand information at all, barely any documentation, no ready-to-use scripts and everyone complaining that our repositories are not signed. We don't have 40h a week to work on the RPMs we build, so it would be really nice to have some smarter scripts that do all the necessary stuff (including repo signing), just as you most probably already have for Factory. And, of course, please consider writing a somewhat more extensive documentation about the whole thing (even if it's just in the wiki). Thanks ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEws+Gr3NMWliFcXcRAibEAJ9ilq55eoEUE5Ef8/ZQpvyREUA0QACffslY yGvUqCdc6ritqXPC/9SKBtE= =egb0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Hi, Pascal Bleser schrieb:
Please also keep us 3rd party packagers in mind when doing all that. Creating repositories for yast2 is a pain as of now (luckily, createrepo is very easy to use but doesn't do the repo signing either).
Really, the repository signing thing in 10.1 must be the worst thing you did to us: no communication or beforehand information at all, barely any documentation, no ready-to-use scripts and everyone complaining that our repositories are not signed.
We don't have 40h a week to work on the RPMs we build, so it would be really nice to have some smarter scripts that do all the necessary stuff (including repo signing), just as you most probably already have for Factory.
The documentation at http://developer.novell.com/wiki/index.php/Creating_a_Kernel_Module_Update_I... works quite well here. Andreas Hanke Isn't that more or less the same as http://en.opensuse.org/Secure_Installation_Sources#The_.22repomd.22_or_.22YU... btw.? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Sun, Jul 23, 2006 at 04:40:29AM +0200, Andreas Hanke wrote:
Hi,
Pascal Bleser schrieb:
Please also keep us 3rd party packagers in mind when doing all that. Creating repositories for yast2 is a pain as of now (luckily, createrepo is very easy to use but doesn't do the repo signing either).
Really, the repository signing thing in 10.1 must be the worst thing you did to us: no communication or beforehand information at all, barely any documentation, no ready-to-use scripts and everyone complaining that our repositories are not signed.
We don't have 40h a week to work on the RPMs we build, so it would be really nice to have some smarter scripts that do all the necessary stuff (including repo signing), just as you most probably already have for Factory.
The documentation at
http://developer.novell.com/wiki/index.php/Creating_a_Kernel_Module_Update_I...
Looks just like http://en.opensuse.org/Creating_a_Kernel_Module_Update_Installation_Source Would it be possible to have http://developer.novell.com/wiki linked somehow to openSUSE.org? -- First we thought the PC was a calculator. Then we found out how to turn numbers into letters with ASCII and we thought it was a typewriter. Then we discovered graphics, and we thought it was television. With the World Wide Web, we've realized it's a brochure. -- Douglas Adams. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Sun, Jul 23, 2006 at 03:23:18AM +0200, Pascal Bleser wrote:
Please also keep us 3rd party packagers in mind when doing all that. Creating repositories for yast2 is a pain as of now (luckily, createrepo is very easy to use but doesn't do the repo signing either).
Not only the 3rd party packager, but eveybody who is interested in SUSE's processes.
Really, the repository signing thing in 10.1 must be the worst thing you did to us: no communication or beforehand information at all, barely any documentation, no ready-to-use scripts and everyone complaining that our repositories are not signed.
Except for the scripts that were alrerady in SUSE, I have not seen many ready-to-use scripts from SUSE.
We don't have 40h a week to work on the RPMs we build, so it would be really nice to have some smarter scripts that do all the necessary stuff (including repo signing), just as you most probably already have for Factory.
And, of course, please consider writing a somewhat more extensive documentation about the whole thing (even if it's just in the wiki).
Not only documentation. It would be also great to have a place where we can see the scripts SUSE is using. Now it looks as if you are saying: "We are open source, but we don't tell you how we do it." It is a pity that we still have to ask for a lot of information, instead of being given the information. :-( -- First we thought the PC was a calculator. Then we found out how to turn numbers into letters with ASCII and we thought it was a typewriter. Then we discovered graphics, and we thought it was television. With the World Wide Web, we've realized it's a brochure. -- Douglas Adams. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Please also keep us 3rd party packagers in mind when doing all that. Creating repositories for yast2 is a pain as of now (luckily, createrepo is very easy to use but doesn't do the repo signing either).
Really, the repository signing thing in 10.1 must be the worst thing you did to us: no communication or beforehand information at all, barely any documentation, no ready-to-use scripts and everyone complaining that our repositories are not signed.
We don't have 40h a week to work on the RPMs we build, so it would be really nice to have some smarter scripts that do all the necessary stuff (including repo signing), just as you most probably already have for Factory.
And, of course, please consider writing a somewhat more extensive documentation about the whole thing (even if it's just in the wiki).
http://en.opensuse.org/Secure_Installation_Sources It is simple. Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* houghi <houghi@houghi.org> [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.
AAARRRRRRGGGGGG. 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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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.
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
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* houghi <houghi@houghi.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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? What I di now most of the time is 'search' and (de-)install the package I find. 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'. -- houghi Please do not toppost http://houghi.org You are about to enter another dimension, a dimension not only of sight and sound but of mind. A journey into a wondrous land of imagination. Next stop, Usenet --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* houghi <houghi@houghi.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Fri, Jul 14, 2006 at 11:57:27AM +0200, Klaus Kaempf wrote:
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.
The problem should only happen with things that you want, not that you need, because they should be left alone because of dependencies in other patterns. I use pin for such things. Would it be possible to somehow have pin into YaST as an extended search method? -- houghi Please do not toppost http://houghi.org You are about to enter another dimension, a dimension not only of sight and sound but of mind. A journey into a wondrous land of imagination. Next stop, Usenet --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* houghi <houghi@houghi.org> [Jul 12. 2006 11:41]:
A realy nice idea. How does it work? Does it still use the *.sel things, or is it something completely new?
Its an extension of the .sel format. But I'd rather come up with a completely new spec. The current .pat format has different tags for "package dependency" and "pattern dependency". Thats confusing. Ideally, the tag name would denote the dependency (requires, conflicts, ...) and the tag value would denote the target (i.e. package:foo, pattern:bar, ...)
So what are the technical differences between what we have and what we will get? Will adding one cause trouble over the other?
Selections don't have hard package dependencies. Packages listed in a selection are selected for installation if available. If not, they're silently ignored. There also nothing which prevents you from de-installing all packages of a selection. The selection still stays installed. Thats bad. Patterns fix all these bugs. A pattern can have hard requirements (to packages or patterns) and force packages being installed. De-installation of required packages will trigger a dependency conflict for the pattern. If you still want selection semantics, just make all pattern requirements weak. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
jdd <jdd@dodin.org> writes:
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)
This is something we plan to handle differently, we will add hardware information to packages in such a way that hardware dependend packages are only installed if needed, Andreas -- Andreas Jaeger, aj@suse.de, 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
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* jdd <jdd@dodin.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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? 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)? -- Don't say that you have no choice, with no one to hear your voice You can shout and make no sound, or whisper up a storm -Robin Trower, 1994 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Glenn Holmer <gholmer@ameritech.net> 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, aj@suse.de, 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
* Glenn Holmer <gholmer@ameritech.net> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Wednesday 12 July 2006 9:41 am, Klaus Kaempf wrote:
* Glenn Holmer <gholmer@ameritech.net> [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 jfunk@funktronics.ca
James Oakley <jfunk@funktronics.ca> writes:
On Wednesday 12 July 2006 9:41 am, Klaus Kaempf wrote:
* Glenn Holmer <gholmer@ameritech.net> [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, aj@suse.de, 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
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. So basically, the best way to maintain this is to do it during package creation time. I'm thinking of the following scenarios: - 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 - The groups can be specified as comment-metadata at the top of the spec file - 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 -- James Oakley jfunk@funktronics.ca
-----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_gro... Desktop categories are here: http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc_desktop... 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 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 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 ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEw1Kfr3NMWliFcXcRAlAEAJ49ADaAj/d1S81llRji62v+XoPZKACfSgQs 3vmi7aQwdHZTy3j6YNRBsh0= =carm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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. 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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* jdd <jdd@dodin.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Klaus Kaempf a écrit :
* jdd <jdd@dodin.org> [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
it's not the problem I was addressing. Packages have content, two packages of similar names can have very different coding. patterns are more like categories in the wiki, only informational. If one looks for a text editor, he should not have to look at "writers" "editors" text processors", but only at one of them. several nearby words can exist, but hopefully with a clear difference in the meaning (editor versus word processor or publisher) 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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* jdd <jdd@dodin.org> [Jul 25. 2006 19:00]:
patterns are more like categories in the wiki, only informational. If one looks for a text editor, he should not have to look at "writers" "editors" text processors", but only at one of them. several nearby words can exist, but hopefully with a clear difference in the meaning (editor versus word processor or publisher)
Sounds more like a list of keywords one can select from and the pattern manager computes the 'best match'. This would be quite a nice feature. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* Pascal Bleser <pascal.bleser@skynet.be> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaus Kaempf wrote:
* Pascal Bleser <pascal.bleser@skynet.be> [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/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* houghi <houghi@houghi.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Tue, Jul 25, 2006 at 09:10:05PM +0200, Klaus Kaempf wrote:
* houghi <houghi@houghi.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* Pascal Bleser <pascal.bleser@skynet.be> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* James Oakley <jfunk@funktronics.ca> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaus Kaempf wrote:
* James Oakley <jfunk@funktronics.ca> [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/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* Pascal Bleser <pascal.bleser@skynet.be> [Jul 23. 2006 12:46]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Klaus Kaempf wrote:
* James Oakley <jfunk@funktronics.ca> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Wednesday 12 July 2006 07:41, Klaus Kaempf wrote:
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.
I like it already. -- Don't say that you have no choice, with no one to hear your voice You can shout and make no sound, or whisper up a storm -Robin Trower, 1994 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* jdd <jdd@dodin.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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
* Kenneth Schneider <suse-list2@bout-tyme.net> [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
Dňa St 12. Júl 2006 17:17 Klaus Kaempf napísal:
* Kenneth Schneider <suse-list2@bout-tyme.net> [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
Kenneth Schneider <suse-list2@bout-tyme.net> 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, aj@suse.de, 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
-----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 <gerberb@zenez.com> 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-----
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* houghi <houghi@houghi.org> [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
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.
-----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 <gerberb@zenez.com> 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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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.
* Boyd Lynn Gerber <gerberb@zenez.com> [Jul 12. 2006 21:35]:
"All Server" "LAMP Server" "Apache Server" "MySQL Server" "P Server" "PHP" "Perl" "Python"
Yes, exactly. Its all about different levels of detail. You have the "product" on top of the hierachy, "patterns" in the middle, and "packages" as the finest granularity. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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
* jdd <jdd@dodin.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
-----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. I really like the new Package Group with patterns. I find it to be really exciting. - -- Boyd Gerber <gerberb@zenez.com> 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/ iD8DBQFEt9laVtBjDid73eYRAmPnAJ9T1I/280jHw0e0qRTJ+3CudmU1VQCgi8O4 ZgPxusGbVMYWZM9fw7RVfM8= =09Yr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
jdd <jdd@dodin.org> 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, aj@suse.de, 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
Andreas Jaeger wrote:
jdd <jdd@dodin.org> 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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
jdd wrote:
Andreas Jaeger wrote:
jdd <jdd@dodin.org> 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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* jdd <jdd@dodin.org> [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 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Klaus Kaempf wrote:
* jdd <jdd@dodin.org> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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 toppost http://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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
houghi <houghi@houghi.org> writes:
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.
What kind of problems do you have? Let's open a new thread for this - and discuss how we can improve updating, Andreas -- Andreas Jaeger, aj@suse.de, 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Schlander wrote:
Fredag 14 juli 2006 19:50 skrev Boyd Lynn Gerber: ... 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.
I totally agree, upgrading packages is a major pain. It's weird though, because it's probably the most common operation users want to make wrt package management (right after installing some package). IMO upgrading packages should be a one-click, show a proposal, give the option to deselect some upgrade operations (if needed), and then a confirmation button, that's it. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEw1SNr3NMWliFcXcRAmSfAJ4kK4QjaSdVJCT/qXA085yWO9UgjgCcDZLu zaNcd60s2C1LdBrKfuTKIEY= =k9Nc -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* Pascal Bleser <pascal.bleser@skynet.be> [Jul 23. 2006 12:50]:
I totally agree, upgrading packages is a major pain.
Its mostly caused by historical reasons. Our main focus was on controlled (and controllable) customer environments for support purposes. Giving the user the ability to upgrade whatever package from any repository was (and still is) a supporters nightmare ;-) And this is still true for most enterprise systems. Sysadmins will never upgrade because a newer version is available but only because of a fixed bug or a required feature.
IMO upgrading packages should be a one-click, show a proposal, give the option to deselect some upgrade operations (if needed), and then a confirmation button, that's it.
zen-updater (and 'rug' on the command line) give you this ability. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
On Tue, Jul 25, 2006 at 07:04:02PM +0200, Klaus Kaempf wrote:
And this is still true for most enterprise systems. Sysadmins will never upgrade because a newer version is available but only because of a fixed bug or a required feature.
If it ain't broke, don't fix it. :-) -- 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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Hello, Am Freitag, 14. Juli 2006 17:02 schrieb jdd:
right now [...] I can't save the selection with 10.1
I posted a possible workaround to the suse-linux mailinglist some time ago, maybe it helps ;-) You can save the package list with rpm -qa --queryformat "%{name}\n" > paketliste Copy the file "paketliste" to the target machine and install all listed packages with xargs yast2 -i < paketliste (Of course, you have to setup the installation sources in YaST before.) To optimize the operation, remove the already installed packages from the list: rpm -qa --queryformat '%{name}\n' | grep -Fvxf - paketliste \ | xargs yast2 -i Disclaimer: This is completely untested! (If you test it, please report back ;-) Regards, Christian Boltz -- We have a "Reinheits-Gebot" (pureness requirement) in Germany per law for beer (showing that our politicians indeed know what they talk about on this matter) [Eberhard Moenkeberg in opensuse] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am Freitag, 14. Juli 2006 17:02 schrieb jdd:
right now [...] I can't save the selection with 10.1
I posted a possible workaround to the suse-linux mailinglist some time ago, maybe it helps ;-)
You can save the package list with rpm -qa --queryformat "%{name}\n" > paketliste
Copy the file "paketliste" to the target machine and install all listed packages with xargs yast2 -i < paketliste (Of course, you have to setup the installation sources in YaST before.)
To optimize the operation, remove the already installed packages from the list: rpm -qa --queryformat '%{name}\n' | grep -Fvxf - paketliste \ | xargs yast2 -i
That does give me a list. The way I use it is to get a system ready for new HW. dump to user.sel the current package selection based on the profiles. For example I have devuser.sel Development System servuser.sel Server System deskuser.sel Dexktop System miniuser.sel Mini Install System alluser.sel All Options System So this new idea of package groupings really matches the way I used the dump feature and install of the OS. I am looking into autoyast but I must admit I really liked the way it was in 10.0 So on new HW I would do a install and do a diff for the differences needed for hardware and the type of profile I wanted. diff -c user.sel devuser.sel > patch.sel I then edit patch.sel to remove duplicates. Then patch < patch.sel Then I would bring this list into yast package selections and go through and add any new items from the new SUSE Linux version. Then dump this file to a new profile.sel where profile is the type of user I want to create. This made it really easy to roll out a New Installation of SUSE Linux for the customer. I would then have an invoice like below after receiving a retail box. 1. New Hardware 2. One box SUSE Linux X 3. Installation and custom setup charge. Then I would later tell them(after using SUSE Linux and falling in love with it) that if they want a good support and a 5 year window on the OS they may/should purchase a SLES X. I would make sure they understand that the 5 year window is from the first release of the product. For example SLES 10 would be aprox Jul 06. This really worked. I am able to get them used to SUSE Linux and see how it benefits them. Then move them to a purchased support contract with Novell should any thing happen to me. So I see this new package grouping as very positive. My only concern is to avoid a problem like what happened with the package manager in 10.1. Does it look like there is sufficent time to get a great product for 10.2? Thanks, - -- Boyd Gerber <gerberb@zenez.com> 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/ iD8DBQFEuAcLVtBjDid73eYRAkqeAJ4p+CXQBvHqHfZUFL38jxF4/kdTEQCeL6vC GWltdGbr+gGnx066WH6pOls= =bjac -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
* Andreas Hanke <andreas.hanke@gmx-topmail.de> [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: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
participants (17)
-
Andreas Hanke -
Andreas Jaeger -
Boyd Lynn Gerber -
Christian Boltz -
Glenn Holmer -
houghi -
James Oakley -
jdd -
Kenneth Schneider -
Klaus Kaempf -
Lars Rupp -
Marcus Meissner -
Martin Schlander -
Pascal Bleser -
Rajko M -
Richard Bos -
Stanislav Visnovsky