[zypp-devel] OS identifier for repositories
Hi, in order to support repository index services (NU type), we need to introduce a function returning an identifier of the OS. Zypp will use this to filter corresponding repositories from the repo index. Currently we use OSName-arch (e.g. sles-10-x86_64). No problem to get the arch, but how to get the OSName? Do we store this somewhere? As for the interface, i suggest to place the functions to ZConfig: /** autodetected OS Id */ ZConfig::defaultSystemId(); /** OS Id zypp uses */ ZConfig::SystemId(); /** Override the zypp OS Id. */ void setSystemId( const std::string sysname_r, const Arch & arch_r ); /** Reset the zypp OS Id to the default. */ void resetSystemId(); maybe also(?) ZConfig::defaultSystemName(); ZConfig::SystemName(); ... cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Jan Kupec wrote:
Hi,
in order to support repository index services (NU type), we need to introduce a function returning an identifier of the OS. Zypp will use this to filter corresponding repositories from the repo index.
Currently we use OSName-arch (e.g. sles-10-x86_64). No problem to get the arch, but how to get the OSName? Do we store this somewhere? I think this is the target, and this values are related to our product naming. So I doubt we should introduce a new concept or?
So this would be distribution + arch Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Duncan Mac-Vicar Prett wrote:
Jan Kupec wrote:
Hi,
in order to support repository index services (NU type), we need to introduce a function returning an identifier of the OS. Zypp will use this to filter corresponding repositories from the repo index.
Currently we use OSName-arch (e.g. sles-10-x86_64). No problem to get the arch, but how to get the OSName? Do we store this somewhere? I think this is the target, and this values are related to our product naming.
Yes. And i found out that we store the product name in /etc/SuSE-release, but the names used there are not the ones use in NU's repoindex.xml, so we need to sync that.
So I doubt we should introduce a new concept or?
If there already is something usable, let's use it. But it must be synced with what is used repoindex.xml
So this would be distribution + arch
yup. And it would be nice (read desirable) if it would be usable across distros. So as far as storing of this value is concerned /etc/SuSE-release is certainly not a good choice. Does LSB define something like this? jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Jan Kupec wrote:
yup. And it would be nice (read desirable) if it would be usable across distros. So as far as storing of this value is concerned /etc/SuSE-release is certainly not a good choice. Does LSB define something like this?
jano
For SLE11 product handling we separated product attribute in 3 parts name (ie: openSUSE) distribution: ( code11 ) flavor ( LiveCD remastered ) plus edition. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Duncan Mac-Vicar Prett wrote:
Jan Kupec wrote:
yup. And it would be nice (read desirable) if it would be usable across distros. So as far as storing of this value is concerned /etc/SuSE-release is certainly not a good choice. Does LSB define something like this?
jano
For SLE11 product handling we separated product attribute in 3 parts
name (ie: openSUSE) distribution: ( code11 ) flavor ( LiveCD remastered )
Ah, i see.. nice, this could be used as you propose (distribution+arch), but we would need to sync with people generating NU Services. j. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thu, Jul 31, 2008 at 11:32:00AM +0200, Jan Kupec wrote:
Currently we use OSName-arch (e.g. sles-10-x86_64). No problem to get the arch, but how to get the OSName? Do we store this somewhere?
The OS is "linux" if you ask rpm... Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thu, Jul 31, Jan Kupec wrote:
Hi,
in order to support repository index services (NU type), we need to introduce a function returning an identifier of the OS. Zypp will use this to filter corresponding repositories from the repo index.
Currently we use OSName-arch (e.g. sles-10-x86_64). No problem to get the arch, but how to get the OSName? Do we store this somewhere?
As for the interface, i suggest to place the functions to ZConfig:
Take into account that our ZConfig handling is not clean, if we use --root. (in fact we had to read the target systems ZConfig and re-initialize all already launches components according to the new settings.) Until we realy do this those values should probably associated with the Target and not with ZConfig. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Michael Andres wrote:
On Thu, Jul 31, Jan Kupec wrote:
Hi,
in order to support repository index services (NU type), we need to introduce a function returning an identifier of the OS. Zypp will use this to filter corresponding repositories from the repo index.
Currently we use OSName-arch (e.g. sles-10-x86_64). No problem to get the arch, but how to get the OSName? Do we store this somewhere?
As for the interface, i suggest to place the functions to ZConfig:
Take into account that our ZConfig handling is not clean, if we use --root.
What exactly is the problem or ambiguity?
(in fact we had to read the target systems ZConfig and re-initialize all already launches components according to the new settings.)
i'm not completely sure what this means :(
Until we realy do this those values should probably associated with the Target and not with ZConfig.
I thought about ZConfing in order to be able to play around with arch/distros other than the system's in --root; i.e. pretend that you are on another system. j. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thu, Jul 31, Jan Kupec wrote:
As for the interface, i suggest to place the functions to ZConfig:
Take into account that our ZConfig handling is not clean, if we use --root.
What exactly is the problem or ambiguity?
If the chrooted system says 'arch = s390' and the outer system says 'arch = i386': We use 'i386' but should use 's390'. The same for the other settings like e.g. solver.onlyRequires. A --root systems Zconfig settings may have no effect. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Michael Andres wrote:
On Thu, Jul 31, Jan Kupec wrote:
As for the interface, i suggest to place the functions to ZConfig: Take into account that our ZConfig handling is not clean, if we use --root. What exactly is the problem or ambiguity?
If the chrooted system says 'arch = s390' and the outer system says 'arch = i386':
We use 'i386' but should use 's390'. The same for the other settings like e.g. solver.onlyRequires.
A --root systems Zconfig settings may have no effect.
Hm, that sounds like something for fixing...? Why not just read the --root system's setttings? For values not specified there, use defaults, just like when in '/'. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thu, Jul 31, Jan Kupec wrote:
Michael Andres wrote:
On Thu, Jul 31, Jan Kupec wrote:
As for the interface, i suggest to place the functions to ZConfig: Take into account that our ZConfig handling is not clean, if we use --root. What exactly is the problem or ambiguity?
If the chrooted system says 'arch = s390' and the outer system says 'arch = i386': We use 'i386' but should use 's390'. The same for the other settings like e.g. solver.onlyRequires. A --root systems Zconfig settings may have no effect.
Hm, that sounds like something for fixing...? Why not just read the --root system's setttings? For values not specified there, use defaults, just like when in '/'.
You can do this as soon as you know the --root. zypper knows it quite early from the commandline. YaST tells it when initializing the target, and that's usually quite late, even after having loaded repositories. This is another usecase for introducing signals, so each component can easily monitor changes in other parts. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (4)
-
Duncan Mac-Vicar Prett -
Jan Kupec -
Michael Andres -
Michael Schroeder