[yast-devel] extra-packages
Hi, I'm afraid this file is completely unmaintained and I'm too lazy^wbusy to file bug reports against every single package - and what bothers me most: I guess tons of dependencies are missing in that file. Greetings, Stephan Yast module autoyast2 needs alice-compat dropped Yast module yast2-http-server needs apache2-mod_ruby dropped Yast module yast2-installation needs xorg-x11-Mesa just Mesa Yast module yast2-kdump needs kdump-helpers just kdump Yast module yast2-ldap-client needs autofs4 dropped since 2005! Yast module yast2-network needs avm_fcdsl dropped Yast module yast2-network needs i4lfirmware the package does not even exist in history Yast module yast2-nis-client needs autofs4 dropped since 2005! Yast module yast2-ntp-client needs xntp Yast module yast2-ntp-client needs xntp-doc renamed recently to ntp - old name still alive Yast module yast2-printer needs hplib dropped Yast module yast2-printer needs hp-officeJet dropped Yast module yast2-samba-server needs samba-pdb dropped Yast module yast2-scanner needs hp-officeJet dropped Yast module yast2-tv needs zapping dropped Yast module yast2-vm needs xen-tools-ioemu dropped -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stephan Kulow napsal(a):
Hi,
I'm afraid this file is completely unmaintained and I'm too lazy^wbusy to file bug reports against every single package - and what bothers me most: I guess tons of dependencies are missing in that file.
It seems there are many dependency errors because of dropping or removing packages. How packagers check their packages dependencies? Packagers themselves almost don't need to do such checking because they generate the dependencies almost always automatically. From time to time, they said, they get a mail from AJ with wrong dependencies to fix. In my opinion, there are two quite easy ways how to improve the current state: * We might enhance our `make package` to check whether packages defined in RPM 'Requires' exist. PDB commandline tool could do that ("but only for STABLE", said nadvornik+anosek). Of course, you need to be authenticated against iChain in PDB. * We might cooperate with packagers and create a unified tool for checking. What do you think of that? Is there a better way than check against PDB? Webpin? Lukas
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
What do you think of that? Is there a better way than check against PDB? Webpin?
Well, you can add all these packages as either requires or build requires to yast2-build-test.spec (remember arch specifics) and you end up in the same list that the packagers get complains from. And yes, it's only against STABLE, but we don't drop or rename packages in released products, so it doesn't matter. Now that extra-packages is machine readable, we could automate the change on every edit. But at first we need to cleanup the current mess, as every maintainer will have to check if the module really tries to install autofs4. Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stephan Kulow napsal(a):
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
What do you think of that? Is there a better way than check against PDB? Webpin?
Well, you can add all these packages as either requires or build requires to yast2-build-test.spec (remember arch specifics) and you end up in the same list that the packagers get complains from.
And yes, it's only against STABLE, but we don't drop or rename packages in released products, so it doesn't matter.
Now that extra-packages is machine readable, we could automate the change on every edit. But at first we need to cleanup the current mess, as every maintainer will have to check if the module really tries to install autofs4.
Well, first it should be said why we have different RPM Requires and BuildRequires. * Some packages are in BR but not in R - They are needed just to build the package because ... hmm, that sounds rather like an error, doesn't it :)? * Some packages are in R but not in BR - Of course, you don't need to install all packages when building the YaST package. It makes the build faster. Of course, if you don't care that BuildRequires will contain 'ALL' packages listed in Requires, we would just simply change the 'make package' command to add everything from 'Requires' to 'BuildRequires'. It would be 'Fast but Furious (II.)' ;) Lukas
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
Of course, if you don't care that BuildRequires will contain 'ALL' packages listed in Requires, we would just simply change the 'make package' command to add everything from 'Requires' to 'BuildRequires'. It would be 'Fast but Furious (II.)' ;)
I don't follow. You can BuildRequire autofs4 and you will get notice when it's dropped. Is this what you're saying? The Requires of yast2-printer should stay untouched. Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stephan Kulow napsal(a):
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
Of course, if you don't care that BuildRequires will contain 'ALL' packages listed in Requires, we would just simply change the 'make package' command to add everything from 'Requires' to 'BuildRequires'. It would be 'Fast but Furious (II.)' ;)
I don't follow. You can BuildRequire autofs4 and you will get notice when it's dropped. Is this what you're saying?
The Requires of yast2-printer should stay untouched.
OK, sorry, I'll write it for human beings (sometimes I forget I'm a YaST developer ;)) * YaST packages define 'BuildRequires' and 'Requires' when creating the RPM. * 'BuildRequires' often contain only those packages that are really needed for the package to get build, on the other hand, 'Requires' contain packages that are needed for the particular YaST package to run properly. * We often don't define packages needed only for run in the 'BuildRequires' because we thought the faster we build a package, the best for us. I'm offering you to take all 'Requires' and merge them with 'BuildRequires' when we use our special 'make package' command that creates the real spec file, tar.bz2 file etc. What would be the ouptut? * Slower build (more packages in BuildRequires than now) * More reliable RPM 'Requires' because we'll find out that they are wrong already in the build time. Actually build won't pass at all with wrong 'Requires' in such case. Hmm, reading this mail from top to bottom doesn't make the feeling better, yes, I'm still a YaST developer :) L.
Lukas Ocilka napsal(a):
Stephan Kulow napsal(a):
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
Ah, hmm, on the other hand ... it seems I'm trying to solve something else. The file extra-packages should be dropped and this list solved by another RPM dependencies. Let's wait for jsrain to write it :) L.
Dne Wednesday 19 of March 2008 11:34:49 Lukas Ocilka napsal(a):
Lukas Ocilka napsal(a):
Stephan Kulow napsal(a):
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
Ah, hmm, on the other hand ... it seems I'm trying to solve something else. The file extra-packages should be dropped and this list solved by another RPM dependencies.
Let's wait for jsrain to write it :)
;-) My idea is that every YaST module which (additionally) installs any packages would have weak dependency on such package. This would have following benefits: - the package would be (by default) dragged in by the solver and user would not be bothered with installation later - the one who needs minimal installation is free to remove it - the list would be with each package, hopefully more on the maintainer's eyes (I know, I'm optimist :-) ) The question is whether we could generate the list of such packages any automated way, ideally via similar check as (I hope) are done for strong dependencies. Stephan? However, the problem to update the list would persist. I can imagine some script which would check most of the cases, but it would never be 100%. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz
Jiri Srain napsal(a):
The question is whether we could generate the list of such packages any automated way, ideally via similar check as (I hope) are done for strong dependencies. Stephan?
However, the problem to update the list would persist. I can imagine some script which would check most of the cases, but it would never be 100%.
We should generate the list of these weak dependencies automatically if possible. For that reason we would have to limit the possibilities how to additionally install such packages. For instance `ycpc -E $file` provides parsable output. The truth is that the list of packages to install needn't be defined statically but dynamically 'if (true) { packages = add (packages, "aaa"); } Think about> If there is any easy and reliable way how get the list of packages, please. L.
My idea is that every YaST module which (additionally) installs any packages would have weak dependency on such package. This would have following benefits: - the package would be (by default) dragged in by the solver and user would not be bothered with installation later This would increase the default installation for the sake of lazy
Am Mittwoch 19 März 2008 schrieb Jiri Srain: maintainers ;(
- the one who needs minimal installation is free to remove it - the list would be with each package, hopefully more on the maintainer's eyes (I know, I'm optimist :-) )
The question is whether we could generate the list of such packages any automated way, ideally via similar check as (I hope) are done for strong dependencies. Stephan? Well, shall I sent out the list of missing packages every day? But autofs4 is dropped since 2005, so I kind of doubt this code is still in place.
Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Stephan Kulow napsal(a):
Am Mittwoch 19 März 2008 schrieb Jiri Srain:
The question is whether we could generate the list of such packages any automated way, ideally via similar check as (I hope) are done for strong dependencies. Stephan? Well, shall I sent out the list of missing packages every day? But autofs4 is dropped since 2005, so I kind of doubt this code is still in place.
Actually the list doesn't seem to maintained anymore. About the missing packages, well, why not :)? If you have enough information (more than developers) you have better either fix it yourself ;) or (better) make developer fix it. L.
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
Stephan Kulow napsal(a):
Am Mittwoch 19 März 2008 schrieb Jiri Srain:
The question is whether we could generate the list of such packages any automated way, ideally via similar check as (I hope) are done for strong dependencies. Stephan?
Well, shall I sent out the list of missing packages every day? But autofs4 is dropped since 2005, so I kind of doubt this code is still in place.
Actually the list doesn't seem to maintained anymore.
About the missing packages, well, why not :)? If you have enough information (more than developers) you have better either fix it yourself ;) or (better) make developer fix it.
That's why I sent out this mail Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hello, On Mar 19 12:47 Jiri Srain wrote (shortened):
My idea is that every YaST module which (additionally) installs any packages would have weak dependency on such package. This would have following benefits: - the package would be (by default) dragged in by the solver
I.e. with "weak dependency" you actually only mean "Recommends" but not "Suggests"? I think "Recommends" is often too strong and "Suggests" is often better. With "Recommends" a zillion of exotic YaST modules could drag in a zillion of exotic packages. In the end it depends on the individual case, for example yast2-printer may recommend cups-drivers and suggest hplip, yast2-scanner may recommend sane-backends and suggest iscan-free Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hi,
On 3/19/2008 at 15:57, Johannes Meixner <jsmeix@suse.de> wrote:
Hello, I.e. with "weak dependency" you actually only mean "Recommends" but not "Suggests"?
I'm not sure, but I think zypper does not handle suggests yet, so it's a very weak dependency... Dominique -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hello, On Mar 19 15:17 Dominique Leuenberger wrote (shortened):
On 3/19/2008 at 15:57, Johannes Meixner <jsmeix@suse.de> wrote:
I.e. with "weak dependency" you actually only mean "Recommends" but not "Suggests"?
I'm not sure, but I think zypper does not handle suggests yet, so it's a very weak dependency...
As far as I understand the meaning of the "extra-packages" file is contains all those packages which could be installed at runtime from particular YaST modules (depending on whatever conditions). Therefore it should not matter what whichever installer tool does. It is the particular YaST module which triggers the installation. All what matters is that there is a central place so that we know all those packages which might be installed at runtime from particular YaST modules so that we can provide those packages on the media or via a repository. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Johannes Meixner <jsmeix@suse.de> [Mar 19. 2008 14:57]:
I.e. with "weak dependency" you actually only mean "Recommends" but not "Suggests"?
I think "Recommends" is often too strong and "Suggests" is often better.
'Suggests' is never evaluated by the dependency solver. Its purely for consumption by the package management application (i.e. yast or zypper) to present a list to the user like Amazons 'Customers Who Bought This Item Also Bought'. 'Recommends' is probably the right choice if you want to ensure a 'reasonable' set of packages installed on a typical system. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Klaus Kaempf napsal(a):
* Johannes Meixner <jsmeix@suse.de> [Mar 19. 2008 14:57]:
I.e. with "weak dependency" you actually only mean "Recommends" but not "Suggests"?
I think "Recommends" is often too strong and "Suggests" is often better.
'Suggests' is never evaluated by the dependency solver. Its purely for consumption by the package management application (i.e. yast or zypper) to present a list to the user like Amazons 'Customers Who Bought This Item Also Bought'.
'Recommends' is probably the right choice if you want to ensure a 'reasonable' set of packages installed on a typical system.
'Recommends' fits only in case a minimal system will not select them by default. In this case 'Suggests' sound better because we actually don't need (and typically don't want) to have these packages installed by default. We actually don't need to have them evaluated by the dependency solver as they haven't been evaluated so far. That's also why we install them in the runtime ... otherwise we could simply require them. Which is not what we want. Lukas
* Lukas Ocilka <lukas.ocilka@suse.cz> [Mar 19. 2008 15:56]:
'Recommends' fits only in case a minimal system will not select them by default. In this case 'Suggests' sound better because we actually don't need (and typically don't want) to have these packages installed by default.
Yes, if these packages are neither needed nor wanted by default, 'suggests' is the right dependency. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Klaus Kaempf napsal(a):
* Lukas Ocilka <lukas.ocilka@suse.cz> [Mar 19. 2008 15:56]:
'Recommends' fits only in case a minimal system will not select them by default. In this case 'Suggests' sound better because we actually don't need (and typically don't want) to have these packages installed by default.
Yes, if these packages are neither needed nor wanted by default, 'suggests' is the right dependency.
I'm afraid there is one more problem with moving extra-packages to something else. I wanted to write a simple script that would get a package name and grep the extra-packages file for its existence. After that all matching lines should have been transformed to "Suggests: $package". But finally I've found that some currently NOARCH packages use several "#if defined(__$arch__)" in that extra-packages file. So moving the content to "Suggests: $package" would mean transforming some NOARCH packages to architecture-dependent just because of suggested packages :( These packages are currently: * yast2-installation (noarch) * yast2-bootloader * yast2-samba-client (noarch) * yast2-fingerprint-reader * yast2-kerberos-client (noarch) * yast2-kdump /Those NOARCH are marked (noarch)/ What do you think of changing them from NOARCH? Isn't there any better solution? Thx && Bye Lukas
Lukas Ocilka <lukas.ocilka@suse.cz> writes:
Klaus Kaempf napsal(a):
* Lukas Ocilka <lukas.ocilka@suse.cz> [Mar 19. 2008 15:56]:
'Recommends' fits only in case a minimal system will not select them by default. In this case 'Suggests' sound better because we actually don't need (and typically don't want) to have these packages installed by default.
Yes, if these packages are neither needed nor wanted by default, 'suggests' is the right dependency.
I'm afraid there is one more problem with moving extra-packages to something else.
I wanted to write a simple script that would get a package name and grep the extra-packages file for its existence. After that all matching lines should have been transformed to "Suggests: $package".
But finally I've found that some currently NOARCH packages use several "#if defined(__$arch__)" in that extra-packages file. So moving the content to "Suggests: $package" would mean transforming some NOARCH packages to architecture-dependent just because of suggested packages :(
Are those requirements still current and correct? Could you give us the list, please?
These packages are currently: * yast2-installation (noarch) * yast2-bootloader * yast2-samba-client (noarch) * yast2-fingerprint-reader * yast2-kerberos-client (noarch) * yast2-kdump
/Those NOARCH are marked (noarch)/
What do you think of changing them from NOARCH? Isn't there any better solution?
Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger napsal(a):
Lukas Ocilka <lukas.ocilka@suse.cz> writes:
But finally I've found that some currently NOARCH packages use several "#if defined(__$arch__)" in that extra-packages file. So moving the content to "Suggests: $package" would mean transforming some NOARCH packages to architecture-dependent just because of suggested packages :(
Are those requirements still current and correct? Could you give us the list, please?
File attached. For simplicity only those "Suggested:$packagename" that are marked architecture-dependent are listed there. For instance yast2-installation has some more but they appear to be NOARCH, so they don't change anything. NOARCH YaST packages affected: * yast2-installation * yast2-samba-client * yast2-kerberos-client Lukas ########################## ### yast2-installation ### ########################## #if defined(__axp__) yast2-installation:milo yast2-installation:aboot yast2-installation:cpml_ev5 yast2-installation:cpml_ev6 #endif #if defined(__ppc__) || defined(__ppc64__) yast2-installation:ibmsis yast2-installation:scsi yast2-installation:mouseemu yast2-installation:pbbuttonsd yast2-installation:powerprefs yast2-installation:mol yast2-installation:sudo yast2-installation:powerpc-utils #endif #if defined(__ia64__) yast2-installation:fpswa #endif #if defined(__x86_64__) yast2-installation:numactl #endif ########################## ### yast2-samba-client ### ########################## #if defined(__x86_64__) || defined(__s390x__) || defined(__ppc__) yast2-samba-client:samba-client-32bit yast2-samba-client:samba-winbind-32bit yast2-samba-client:krb5-32bit #endif #if defined(__ia64__) yast2-samba-client:samba-client-x86 yast2-samba-client:samba-winbind-x86 yast2-samba-client:krb5-x86 #endif #if defined(__ppc64__) yast2-samba-client:samba-client-64bit yast2-samba-client:samba-winbind-64bit yast2-samba-client:krb5-64bit #endif ############################# ### yast2-kerberos-client ### ############################# #if defined(__ia64__) yast2-kerberos-client:krb5-x86 yast2-kerberos-client:pam_krb5-x86 #endif #if defined(__ppc64__) yast2-kerberos-client:krb5-64bit yast2-kerberos-client:pam_krb5-64bit #endif #if defined(__x86_64__) || defined(__s390x__) || defined(__ppc__) yast2-kerberos-client:krb5-32bit yast2-kerberos-client:pam_krb5-32bit #endif
Lukas Ocilka napsal(a):
Andreas Jaeger napsal(a):
But finally I've found that some currently NOARCH packages use several "#if defined(__$arch__)" in that extra-packages file. So moving the content to "Suggests: $package" would mean transforming some NOARCH packages to architecture-dependent just because of suggested packages :( Are those requirements still current and correct? Could you give us the
Lukas Ocilka <lukas.ocilka@suse.cz> writes: list, please?
File attached.
For simplicity only those "Suggested:$packagename" that are marked architecture-dependent are listed there. For instance yast2-installation has some more but they appear to be NOARCH, so they don't change anything.
NOARCH YaST packages affected: * yast2-installation * yast2-samba-client * yast2-kerberos-client
Hmm, while checking the list ... I've realized that, for instance, those packages listed for yast2-installation should go somewhere else. * Bootloader (milo, aboot, cpml_ev5, cpml_ev6) * Base pattern (sudo) * Enhanced base PPC patterm (ibmsis, scsi, mouseemu, pbbuttonsd, powerprefs, mol, powerpc-utils) * ... no idea for (fpswa, numactl) L.
On Thu, 20 Mar 2008, Lukas Ocilka wrote:
Lukas Ocilka napsal(a):
Andreas Jaeger napsal(a):
But finally I've found that some currently NOARCH packages use several "#if defined(__$arch__)" in that extra-packages file. So moving the content to "Suggests: $package" would mean transforming some NOARCH packages to architecture-dependent just because of suggested packages :( Are those requirements still current and correct? Could you give us the
Lukas Ocilka <lukas.ocilka@suse.cz> writes: list, please?
File attached.
For simplicity only those "Suggested:$packagename" that are marked architecture-dependent are listed there. For instance yast2-installation has some more but they appear to be NOARCH, so they don't change anything.
NOARCH YaST packages affected: * yast2-installation * yast2-samba-client * yast2-kerberos-client
Hmm, while checking the list ... I've realized that, for instance, those packages listed for yast2-installation should go somewhere else.
* Bootloader (milo, aboot, cpml_ev5, cpml_ev6) * Base pattern (sudo) * Enhanced base PPC patterm (ibmsis, scsi, mouseemu, pbbuttonsd, powerprefs, mol, powerpc-utils) * ... no idea for (fpswa, numactl)
Does this actually matter? What would happen if we have Suggests to a package which is not available? I mean to have Suggests:milo in bootloader despite it's noarch could possibly have no harm on architectures which do not have that package (in a theoretical situation we actually use Suggests for anything). Michal -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Am Freitag 21 März 2008 schrieb Michal Svec:
Does this actually matter? What would happen if we have Suggests to a package which is not available?
I mean to have Suggests:milo in bootloader despite it's noarch could possibly have no harm on architectures which do not have that package (in a theoretical situation we actually use Suggests for anything).
It's great that everyone tries to solve so many problems, but can we please remember for a short moment the problem that extra-packages tries to solve? The goal is to have a way to check if all packages possibly dragged in by yast2-bootloader _on that arch_ on the medium _of that arch_. So yes, you can suggest everything and we would not be able to do any kind of medium afterwards. So the goals: 1. (mandatory) we need a list of requirements somewhere that media can be checked against 2. (desirable) it should be easy for yast maintainers to ignore it. Making packages arch-specific for the sake of moving the information into the spec file makes this basically a killer. If you think extra-packages as file "somewhere" is to be ignored, then please add the information in yast/trunk/bootloader/EXTRA_DEPS or something. Suggests are pointless and hard to parse and you never know if the suggests is a real one or one of the "represents weak yast deps" kind. Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Lukas Ocilka <lukas.ocilka@suse.cz> writes:
Andreas Jaeger napsal(a):
Lukas Ocilka <lukas.ocilka@suse.cz> writes:
But finally I've found that some currently NOARCH packages use several "#if defined(__$arch__)" in that extra-packages file. So moving the content to "Suggests: $package" would mean transforming some NOARCH packages to architecture-dependent just because of suggested packages :(
Are those requirements still current and correct? Could you give us the list, please?
File attached.
For simplicity only those "Suggested:$packagename" that are marked architecture-dependent are listed there. For instance yast2-installation has some more but they appear to be NOARCH, so they don't change anything.
NOARCH YaST packages affected: * yast2-installation * yast2-samba-client * yast2-kerberos-client
Lukas ########################## ### yast2-installation ### ##########################
#if defined(__axp__) yast2-installation:milo yast2-installation:aboot yast2-installation:cpml_ev5 yast2-installation:cpml_ev6 #endif
Remove completely, axp is not supported anymore.
#if defined(__ppc__) || defined(__ppc64__) yast2-installation:ibmsis yast2-installation:scsi yast2-installation:mouseemu yast2-installation:pbbuttonsd yast2-installation:powerprefs yast2-installation:mol yast2-installation:sudo yast2-installation:powerpc-utils #endif
Why think most of these should be done in another way. sudo looks wrong and the rest is hardware support that can be handled differently.
#if defined(__ia64__) yast2-installation:fpswa #endif
Does yast2-installation really need this - or can we install it via patterns?
#if defined(__x86_64__) yast2-installation:numactl #endif
Why does yast2-installation need numactl? It should be installed via patterns.
########################## ### yast2-samba-client ### ##########################
#if defined(__x86_64__) || defined(__s390x__) || defined(__ppc__) yast2-samba-client:samba-client-32bit yast2-samba-client:samba-winbind-32bit yast2-samba-client:krb5-32bit #endif
#if defined(__ia64__) yast2-samba-client:samba-client-x86 yast2-samba-client:samba-winbind-x86 yast2-samba-client:krb5-x86 #endif
#if defined(__ppc64__) yast2-samba-client:samba-client-64bit yast2-samba-client:samba-winbind-64bit yast2-samba-client:krb5-64bit #endif
############################# ### yast2-kerberos-client ### #############################
#if defined(__ia64__) yast2-kerberos-client:krb5-x86 yast2-kerberos-client:pam_krb5-x86 #endif
#if defined(__ppc64__) yast2-kerberos-client:krb5-64bit yast2-kerberos-client:pam_krb5-64bit #endif
#if defined(__x86_64__) || defined(__s390x__) || defined(__ppc__) yast2-kerberos-client:krb5-32bit yast2-kerberos-client:pam_krb5-32bit #endif
Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Mittwoch 19 März 2008 schrieb Klaus Kaempf:
* Johannes Meixner <jsmeix@suse.de> [Mar 19. 2008 14:57]:
I.e. with "weak dependency" you actually only mean "Recommends" but not "Suggests"?
I think "Recommends" is often too strong and "Suggests" is often better.
'Suggests' is never evaluated by the dependency solver. Its purely for consumption by the package management application (i.e. yast or zypper) to present a list to the user like Amazons 'Customers Who Bought This Item Also Bought'.
'Recommends' is probably the right choice if you want to ensure a 'reasonable' set of packages installed on a typical system.
But we don't. The feature behind this is that all yast modules are installed, but only if you configure LDAP you also get all ldap services installed. So recommending LDAP from yast2-ldap would imply that we also will not have LDAP offering in second stage. Greetings, Stephan -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On st 19. března 2008, Lukas Ocilka wrote:
Lukas Ocilka napsal(a):
Stephan Kulow napsal(a):
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
Ah, hmm, on the other hand ... it seems I'm trying to solve something else. The file extra-packages should be dropped and this list solved by another RPM dependencies.
Coolo, do you remember when I requested exactly this for yast2-ldap/nis/samba-client packages? Bug 357210. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Lukas Ocilka <lukas.ocilka@suse.cz> writes:
Stephan Kulow napsal(a):
Am Mittwoch 19 März 2008 schrieb Lukas Ocilka:
Of course, if you don't care that BuildRequires will contain 'ALL' packages listed in Requires, we would just simply change the 'make package' command to add everything from 'Requires' to 'BuildRequires'. It would be 'Fast but Furious (II.)' ;)
I don't follow. You can BuildRequire autofs4 and you will get notice when it's dropped. Is this what you're saying?
The Requires of yast2-printer should stay untouched.
OK, sorry, I'll write it for human beings (sometimes I forget I'm a YaST developer ;))
* YaST packages define 'BuildRequires' and 'Requires' when creating the RPM. * 'BuildRequires' often contain only those packages that are really needed for the package to get build, on the other hand, 'Requires' contain packages that are needed for the particular YaST package to run properly. * We often don't define packages needed only for run in the 'BuildRequires' because we thought the faster we build a package, the best for us.
We have checks in the BuildSystem and during CD making that check for all the requires. This happens at a later time. But if you have e.g. a package that BuildRequires all yast-packages - like yast2-build-test does - it will install all the Requires of the BuildRequires. This should be enough IMO - if somebody checks failures of yast2-build-test and changes then the packages with wrong Requires, Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger napsal(a):
We have checks in the BuildSystem and during CD making that check for all the requires. This happens at a later time. But if you have e.g. a package that BuildRequires all yast-packages - like yast2-build-test does - it will install all the Requires of the BuildRequires.
This should be enough IMO - if somebody checks failures of yast2-build-test and changes then the packages with wrong Requires,
First of all, I have to admit I got it wrong. Second, we should get rid of extra-packages somehow elegantly (I hope jsrain will write his idea here soon). Third, all '[Build]Requires', 'Recommends', 'Wants', 'Conflicts' (?), etc. should be checked during the build-time (maybe in post-build-scripts) whether the somehow-required resolvables (eh) really exist. Thx && Bye Lukas
On Wednesday 19 March 2008 10:53, Lukas Ocilka wrote:
* We might enhance our `make package` to check whether packages defined in RPM 'Requires' exist. PDB commandline tool could do that ("but only for STABLE", said nadvornik+anosek). Of course, you need to be authenticated against iChain in PDB.
Please don't. "make check" already does a lot more things that are healthy to do at this point. If we add even more, it keeps failing, and YaST2 package maintainers will be forced to use "make package-local" which bypasses almost all checks. Plus, pdb-commandline and its authentication would make our development environment even more fragile (there have been times when this didn't work for me at all for a long time). Checking for those dependency problems is a good thing. But this is something that can and should be done with a separate tool every once in a while. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hello, On Mar 19 08:42 Stephan Kulow wrote (shortened):
Yast module yast2-printer needs hplib
There is no package named hplib - it is hplip. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (10)
-
Andreas Jaeger -
Dominique Leuenberger -
Jiri Srain -
Jiří Suchomel -
Johannes Meixner -
Klaus Kaempf -
Lukas Ocilka -
Michal Svec -
Stefan Hundhammer -
Stephan Kulow