houghi 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

houghi 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

-----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/ /\\ _\_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

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

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

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 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

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

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

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

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

Glenn Holmer 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

On Wednesday 12 July 2006 9:41 am, Klaus Kaempf wrote:

* Glenn Holmer [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

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

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

Klaus Kaempf a écrit :

* jdd [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

* Pascal Bleser [Jul 23. 2006 12:42]: [...]

Now, with those patterns, if they're not a closed, well-defined list of options to choose from, we will most probably end up with chaos.

Well, actually I don't think so. We'll probably get as much (or better as less) chaos as with packages. 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

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

On Tue, Jul 25, 2006 at 09:10:05PM +0200, Klaus Kaempf wrote:

* houghi [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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaus Kaempf wrote:

* James Oakley [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/ /\\ _\_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

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

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

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

Dňa St 12. Júl 2006 17:17 Klaus Kaempf napísal:

* Kenneth Schneider [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

* houghi [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

-----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 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

* Boyd Lynn Gerber [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

* jdd [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

-----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 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

jdd 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

jdd wrote:

Andreas Jaeger wrote:

...

jdd 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

* jdd [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

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

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

-----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/ /\\ _\_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

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

-----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 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

* Andreas Hanke [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