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