-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Oakley wrote: > On Wednesday 12 July 2006 12:25 pm, Andreas Jaeger wrote: >> You got it ;-). It's really powerful and you could do such stuff. >> >> The question is do we want to do it this way? It makes it difficult >> to maintain them... > > It does introduce an extra step, at least. Whenever you create a package, you > have to choose a group. You can think of this as just another kind of group. > > Also, when you split a package, you are consciously thinking about this > grouping. PostgreSQL is obviously a database, and the postgresql-python > subpackage is clearly meant for Python.
More or less. When you split a package, you are thinking of dependencies and making certain features (and dependencies) optional when possible (see the "miniSUSE" thread about this) to avoid ending up with a 30GB base system ;) > So basically, the best way to maintain this is to do it during package > creation time. I'm thinking of the following scenarios: Let me just address a few things here regarding "package creation time". Currently, we already have two categorizations: 1) the RPM "Group:" tag 2) the categories for .desktop files (menu entries for KDE and GNOME) Fortunately, there's a closed set of options, as defined in the "SUSE Package Conventions": http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc.html RPM Groups are here: http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc_rpm_groups.html Desktop categories are here: http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc_desktop_menu.html#spc_dm_category_list As the set of options there is well-defined, it's usually quite easy to pick the right one. Now, with those patterns, if they're not a closed, well-defined list of options to choose from, we will most probably end up with chaos. Please always keep in mind that not all the RPMs are made by SUSE packagers, there are also quite a few "community packagers" out there (like me). We should also be able to use that patterns feature and put the packages we build into those. > - The groups can be selected when the package is added to the buildservice. > You are asked for name, summary, and description already. This is just one or > two more pieces of metadata Build Service is just one of the options to provide RPMs for SUSE Linux. Many (critical, as far as most end-users are concerned) packages will never show up in there (just think of mad, lame, full-featured amarok, etc...). If the pattern a package is part of is stored in the Build Service metadata, then the whole list of .pat files can only be generated from the Build Service. The SUSE packagers also have their internal build system though (and I don't think it's planned to move the whole distribution to the Build Service). > - The groups can be specified as comment-metadata at the top of the spec file Well.. yeah... that should be the last option to consider. Introducing proprietary spec file tags through comments is really, really bad practice. It is used in the Build Service where it is rather appropriate (and where other options would be more difficult to handle), but it's not a nice way of doing things. > - If RPM is modified, new tags could be added, allowing the data to be placed > directly in the header. With this, you could easily generate the selection > files for an arbitrary collection of RPMs Forget modifying RPM with proprietary extensions. I really hope that will never, ever happen. What about other distributions that don't give a cent about those patterns ? Unless patterns become a native feature of RPM, RPM must not be modified to support that. Anyhow, that pattern infrastructure must be "pluggable" - i.e. every package must be able to define what pattern it is part of. I don't see why that information should be stored in spec files, that only makes things more complex (IMO) because you have to run over all the spec files to collect the information and create the .pat files. I think it would be much better to just store the information directly in .pat files in repositories (in suse/setup/descr), in a simple format, to just create or modify those files with a simple text editor (XML would be an option as well - less human-readable/editable but validation would be a plus). The trick is just that for a given .pat file (e.g. "development-database-server.pat"), YaST2 (or libzypp or ZMD or whatever) must be capable of "merging" .pat files that have the same name across all the repositories it has in its list. An example: - - you have two repositories configured in your list: SUSE Linux 10.2 and Packman (for SUSE Linux 10.2) - - in the SL 10.2 repository, in suse/setup/descr/, you have a file called "development-database-server.pat", that includes stuff like mysql, mysql-Max, postgresql-server, ...) - - in the Packman repository, in suse/setup/descr/, you also have a file called "development-database-server.pat", that includes e.g. firebird YaST2 must be 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/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
