[softwaremgmt] obtain source repo directly via rpm header
What about simply utilizing a previously unused rpm-tag to directly determine via the rpm-header where a package came from? Then we do not need to parse the whole history just for this purpose! I have had a look at all header entries and have found a promising up to now unused candidate: RPMTAG_SOURCE For the future RPMTAG_SOURCE could carry the Buildservice-URL a package is provided via. SOURCE = http://download.opensuse.org/repositories/KDE:/Community/openSUSE_11.1 RPMTAG_DISTRIBUTION could then no longer be complicated with the info already present in RPMTAG_ARCH, but extended with a hint like Buildservice/Core: now: DISTRIBUTION = openSUSE 11.0 (X86-64) ARCH = x86_64 as proposed: DISTRIBUTION = openSUSE 11.0 / Buildservice ARCH = x86_64 .. then I can wrack my fresh history parser implementation; slurp. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
* Elmar Stellnberger
What about simply utilizing a previously unused rpm-tag to directly determine via the rpm-header where a package came from? Then we do not need to parse the whole history just for this purpose!
What are you trying to achieve ? Both values provide different information. The zypper history shows the repo the package was downloaded from. The rpm distribution and vendor tags show where the package was build.
I have had a look at all header entries and have found a promising up to now unused candidate: RPMTAG_SOURCE
RPMTAG_SOURCE already has a different definition: A list of the source files that are present in the SRPM package. All files listed here will be placed in the relevant C<SOURCES> directory when building from this SRPM. All source files listed in the original spec are listed here, even if some were excluded by the B<NOSOURCE> tag defined earlier.
For the future RPMTAG_SOURCE could carry the Buildservice-URL a package is provided via. SOURCE = http://download.opensuse.org/repositories/KDE:/Community/openSUSE_11.1
The repo URL is of little value since it just shows the distribution channel, not the origin.
RPMTAG_DISTRIBUTION could then no longer be complicated with the info already present in RPMTAG_ARCH, but extended with a hint like Buildservice/Core:
now: DISTRIBUTION = openSUSE 11.0 (X86-64) ARCH = x86_64
as proposed: DISTRIBUTION = openSUSE 11.0 / Buildservice ARCH = x86_64
Well, DISTRIBUTION should describe the 'build environment': A text label identifying the name given to the overall larger distribution the package itself is a part of. To identify the package origin, two tags are useful: RPMTAG_PACKAGER Name of the group/company/individual who built the package. RPMTAG_VENDOR An alternate identifier for the company that created and provided the package. But this topic is now more likely suited for opensuse-buildservice@opensuse.org or opensuse-packaging@opensuse.org ;-) Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Elmar Stellnberger wrote:
What about simply utilizing a previously unused rpm-tag to directly determine via the rpm-header where a package came from? Then we do not need to parse the whole history just for this purpose! I have had a look at all header entries and have found a promising up to now unused candidate: RPMTAG_SOURCE
For the future RPMTAG_SOURCE could carry the Buildservice-URL a package is provided via. SOURCE = http://download.opensuse.org/repositories/KDE:/Community/openSUSE_11.1
RPMTAG_DISTRIBUTION could then no longer be complicated with the info already present in RPMTAG_ARCH, but extended with a hint like Buildservice/Core:
How do you handle mirrors in this case? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
On Thursday 14 May 2009 15:36:29 Duncan Mac-Vicar Prett wrote:
Elmar Stellnberger wrote:
What about simply utilizing a previously unused rpm-tag to directly determine via the rpm-header where a package came from? Then we do not need to parse the whole history just for this purpose! I have had a look at all header entries and have found a promising up to now unused candidate: RPMTAG_SOURCE
For the future RPMTAG_SOURCE could carry the Buildservice-URL a package is provided via. SOURCE = http://download.opensuse.org/repositories/KDE:/Community/openSUSE_11.1
well, you know this is already present ? # rpm -qp --qf "%{DISTURL}\n" kde3-mailody/kde3-mailody-0.5.0-1.1.x86_64.rpm obs://build.opensuse.org/KDE:Community/openSUSE_11.1/8509726c16b137b6f090460af5067d4c-kde3-mailody $OBS_INSTANCE/$PROJECT/$REPOSITORY/$SRCREV-$PACKAGE
RPMTAG_DISTRIBUTION could then no longer be complicated with the info already present in RPMTAG_ARCH, but extended with a hint like Buildservice/Core:
How do you handle mirrors in this case?
-- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux Fatou 2.6.29-6-default #1 SMP 2009-03-24 15:38:18 +0100 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
rpm -q --qf "%{DISTURL}\n" kdebase3 kdebase3-session kde4-kmahjongg kdeaddons3-kate python-kde3 kdepim3 srcrep:ea2b965c6714375c5b04984b9dc1f7f4-kdebase3 srcrep:ea2b965c6714375c5b04984b9dc1f7f4-kdebase3 srcrep:3a7c5e0e03ccc7bf009771b44c427695-kdegames4 srcrep:4820cd868700d8d3fdc67177fd85528c-kdeaddons3 srcrep:6884e1a3f7a8dd2a194823ce62df73eb-python-kde3 obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard/1b7482b2cf00d011a39eff2d5a03c3b1-kdepim3
It seems to return some kind of classification scheme intermangeled with a hash key for most cases. What I have proposed is to supply the primary repository URL the package can be redownloaded from in order to group packages by their zypp-installation source. However obs://build.suse.de/SUSE is no valid URL where I could redownload the package from. Ruediger Oertel schrieb:
On Thursday 14 May 2009 15:36:29 Duncan Mac-Vicar Prett wrote:
Elmar Stellnberger wrote:
What about simply utilizing a previously unused rpm-tag to directly determine via the rpm-header where a package came from? Then we do not need to parse the whole history just for this purpose! I have had a look at all header entries and have found a promising up to now unused candidate: RPMTAG_SOURCE
For the future RPMTAG_SOURCE could carry the Buildservice-URL a package is provided via. SOURCE = http://download.opensuse.org/repositories/KDE:/Community/openSUSE_11.1
well, you know this is already present ? # rpm -qp --qf "%{DISTURL}\n" kde3-mailody/kde3-mailody-0.5.0-1.1.x86_64.rpm obs://build.opensuse.org/KDE:Community/openSUSE_11.1/8509726c16b137b6f090460af5067d4c-kde3-mailody
$OBS_INSTANCE/$PROJECT/$REPOSITORY/$SRCREV-$PACKAGE
RPMTAG_DISTRIBUTION could then no longer be complicated with the info already present in RPMTAG_ARCH, but extended with a hint like Buildservice/Core: How do you handle mirrors in this case?
-- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
On Thursday 14 May 2009 20:17:41 Elmar Stellnberger wrote:
rpm -q --qf "%{DISTURL}\n" kdebase3 kdebase3-session kde4-kmahjongg
kdeaddons3-kate python-kde3 kdepim3 srcrep:ea2b965c6714375c5b04984b9dc1f7f4-kdebase3 srcrep:ea2b965c6714375c5b04984b9dc1f7f4-kdebase3 srcrep:3a7c5e0e03ccc7bf009771b44c427695-kdegames4 srcrep:4820cd868700d8d3fdc67177fd85528c-kdeaddons3 srcrep:6884e1a3f7a8dd2a194823ce62df73eb-python-kde3 obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard/1b7482b2cf00d01 1a39eff2d5a03c3b1-kdepim3
It seems to return some kind of classification scheme intermangeled with a hash key for most cases. What I have proposed is to supply the primary repository URL the package can be redownloaded from in order to group packages by their zypp-installation source. However obs://build.suse.de/SUSE is no valid URL where I could redownload the package from.
well, the "srcrep:$SRCID-$PACKAGENAME" type entries in DISTURL are either old ones (before we did the change in OBS) or packages not built by the buildservice but by the internal autobuild system. Current packages in Factory all have the newer type DISTURL entry and so have all packages built now in our buildservice instances. # rpm -qp --qf "%{DISTURL}\n" aaa_base-11.2-25.1.i586.rpm obs://build.opensuse.org/openSUSE:Factory/standard/6403dd6eefcf978497ed22fedecf505d- aaa_base # rpm -qp --qf "%{DISTURL}\n" aaa_base-11.1-10007.15.1.i586.rpm obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard/7e6825744b2f0ba55cdd7a35d598266f- aaa_base the first one was built in the opensuse.org buildservice and can be downloaded via it's repo server area, so "obs://build.opensuse.org/" maps to "http://download.opensuse.org/repositories/" the second one is an update package. "obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard" maps to "http://download.opensuse.org/update/11.1/" but that repo is not an output repository of the buildservice since it contains other data as well (updateinfo,deltarpms,susedata etc.) The packages are built in the internal instance mostly because of the need to be able to build updates even before a coordinated release date for example and the built packages are then processed further and end up in that update repository as they are released (at that same point in time the packages are available together with their sources in https://build.opensuse.org/project/show?project=openSUSE:11.1:Update which however is just a project to build against and not publishing sources or binaries since they are injected as I just wrote. So while these might not be direct URLS to repositories, these still can be used to _hint_ where a package came from. BUT: a package built in one project/repository could end up in more than one output repository available to the installer. This can be true for update repositories of several products in a product family or in a much simpler case: Think of openSUSE 11.1: The same (identical) package is available on your install media (for example a CD,DVD) and on the FTP install source http://download.opensuse.org/distribution/11.1/repo/oss/suse/ and there could be another one at http://download.opensuse.org/repositories/openSUSE:/11.1:/standard (which does not exist since it's disabled) but I guess this explains the idea. In short: at the time of creation of the rpm, when the RPMTAGs are filled out, the package does not know yet in which (and how many) repositories it can end up. So except for really modifying the binary rpms at the time when a output repository is put together and its metadata is written (for example using createrepo) the binary rpms can't have that data as it's not known yet during build. -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux MacBookRudi 2.6.29-6-default #1 SMP 2009-03-24 15:38:18 +0100 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Ruediger Oertel schrieb:
On Thursday 14 May 2009 20:17:41 Elmar Stellnberger wrote:
rpm -q --qf "%{DISTURL}\n" kdebase3 kdebase3-session kde4-kmahjongg kdeaddons3-kate python-kde3 kdepim3 srcrep:ea2b965c6714375c5b04984b9dc1f7f4-kdebase3 srcrep:ea2b965c6714375c5b04984b9dc1f7f4-kdebase3 srcrep:3a7c5e0e03ccc7bf009771b44c427695-kdegames4 srcrep:4820cd868700d8d3fdc67177fd85528c-kdeaddons3 srcrep:6884e1a3f7a8dd2a194823ce62df73eb-python-kde3 obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard/1b7482b2cf00d01 1a39eff2d5a03c3b1-kdepim3
It seems to return some kind of classification scheme intermangeled with a hash key for most cases. What I have proposed is to supply the primary repository URL the package can be redownloaded from in order to group packages by their zypp-installation source. However obs://build.suse.de/SUSE is no valid URL where I could redownload the package from.
well, the "srcrep:$SRCID-$PACKAGENAME" type entries in DISTURL are either old ones (before we did the change in OBS) or packages not built by the buildservice but by the internal autobuild system.
Current packages in Factory all have the newer type DISTURL entry and so have all packages built now in our buildservice instances. # rpm -qp --qf "%{DISTURL}\n" aaa_base-11.2-25.1.i586.rpm obs://build.opensuse.org/openSUSE:Factory/standard/6403dd6eefcf978497ed22fedecf505d- aaa_base # rpm -qp --qf "%{DISTURL}\n" aaa_base-11.1-10007.15.1.i586.rpm obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard/7e6825744b2f0ba55cdd7a35d598266f- aaa_base
the first one was built in the opensuse.org buildservice and can be downloaded via it's repo server area, so "obs://build.opensuse.org/" maps to "http://download.opensuse.org/repositories/"
the second one is an update package. "obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard" maps to "http://download.opensuse.org/update/11.1/" but that repo is not an output repository of the buildservice since it contains other data as well (updateinfo,deltarpms,susedata etc.) The packages are built in the internal instance mostly because of the need to be able to build updates even before a coordinated release date for example and the built packages are then processed further and end up in that update repository as they are released (at that same point in time the packages are available together with their sources in https://build.opensuse.org/project/show?project=openSUSE:11.1:Update which however is just a project to build against and not publishing sources or binaries since they are injected as I just wrote.
So while these might not be direct URLS to repositories, these still can be used to _hint_ where a package came from.
BUT: a package built in one project/repository could end up in more than one output repository available to the installer. This can be true for update repositories of several products in a product family or in a much simpler case: Think of openSUSE 11.1: The same (identical) package is available on your install media (for example a CD,DVD) and on the FTP install source http://download.opensuse.org/distribution/11.1/repo/oss/suse/ and there could be another one at http://download.opensuse.org/repositories/openSUSE:/11.1:/standard (which does not exist since it's disabled) but I guess this explains the idea.
In short: at the time of creation of the rpm, when the RPMTAGs are filled out, the package does not know yet in which (and how many) repositories it can end up. So except for really modifying the binary rpms at the time when a output repository is put together and its metadata is written (for example using createrepo) the binary rpms can't have that data as it's not known yet during build.
What about injecting the final download URI into packages once they are made available in a public repo (DVD, repo-oss, repo-non-oss, Update)? Although the newly implemented internal mechanism comes very close to my proposal that would have the following advantages: * more user friendly tagging (no URL translation needed) * contains additional info: DVD / repo-oss i.e. tagging as DVD, maybe as DVD-oss / DVD-non-oss is important for package stats taking precedence over repo-oss/repo-non-oss * just stating the repository directly addable via zypper, not the URI of the package itself is advantageous for stats as well as using zypper * already argued advantages over history analysis + more simple It should be possible just to modify the rpm-header of an already created package, shouldn't it? -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Elmar Stellnberger wrote:
the first one was built in the opensuse.org buildservice and can be downloaded via it's repo server area, so "obs://build.opensuse.org/" maps to "http://download.opensuse.org/repositories/"
is there a defined mapping convention , or api call to go from the instance to the download area of the instance? -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Am Freitag, 15. Mai 2009 14:24:26 schrieb Duncan Mac-Vicar Prett:
Elmar Stellnberger wrote:
the first one was built in the opensuse.org buildservice and can be downloaded via it's repo server area, so "obs://build.opensuse.org/" maps to "http://download.opensuse.org/repositories/"
is there a defined mapping convention , or api call to go from the instance to the download area of the instance?
it is part of the buildinfo meta data (see the url when doing "osc -d build ..." for some package. We could may create a redirect from build.o.o/download to the configured download server, but that would mean quite a lot traffic on our developer interface. I am not sure that I like this idea. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Adrian Schröter schrieb:
Am Freitag, 15. Mai 2009 14:24:26 schrieb Duncan Mac-Vicar Prett:
Elmar Stellnberger wrote:
the first one was built in the opensuse.org buildservice and can be downloaded via it's repo server area, so "obs://build.opensuse.org/" maps to "http://download.opensuse.org/repositories/" is there a defined mapping convention , or api call to go from the instance to the download area of the instance?
it is part of the buildinfo meta data (see the url when doing "osc -d build ..." for some package.
We could may create a redirect from build.o.o/download to the configured download server, but that would mean quite a lot traffic on our developer interface. I am not sure that I like this idea.
Why not incorporate the URI as argued directly into the rpm header; then we do not need a redirect. Furthermore we do not need osc for obtaining the final download URI. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Elmar Stellnberger wrote:
We could may create a redirect from build.o.o/download to the configured download server, but that would mean quite a lot traffic on our developer interface. I am not sure that I like this idea.
Why not incorporate the URI as argued directly into the rpm header; then we do not need a redirect. Furthermore we do not need osc for obtaining the final download URI.
Because if one thing can be deriver from the other, then there is no need to duplicate information. Also, having both in there limits for example any url changes. -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Duncan Mac-Vicar Prett schrieb:
Elmar Stellnberger wrote:
We could may create a redirect from build.o.o/download to the configured download server, but that would mean quite a lot traffic on our developer interface. I am not sure that I like this idea.
Why not incorporate the URI as argued directly into the rpm header; then we do not need a redirect. Furthermore we do not need osc for obtaining the final download URI.
Because if one thing can be deriver from the other, then there is no need to duplicate information. There will always be at least one additional information the final URI will contain: whether a package is available from DVD or not.
The argument for not providing such an rpm tag directly was that the final URI is not determined at package creation time and will therefore contain additional information (see previous mails) *. My counter argument was to simply inject the primary download repo URI with hindsight into the header of an already created rpm once it is made available on a public repo.
Also, having both in there limits for example any url changes.
In a fact both fields would then have to be changed instead of one; no principial infeasibility. Nonetheless I can not think of any possibility where such a change should be necessary. A package burnt on final distro-dvds will on from the release date always be available from there so that no change should be necessary. That is the same for other repos as well so that the header injection needs to take place only once at the release date of a new distro. There is no problem on making newer or same versions avaiable on other repos since this tag is meant to contain the primary repo URI, not the mirror URI. * that is where the cat bites into its own tail. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Ruediger Oertel schrieb:
On Thursday 14 May 2009 20:17:41 Elmar Stellnberger wrote:
rpm -q --qf "%{DISTURL}\n" kdebase3 kdebase3-session kde4-kmahjongg kdeaddons3-kate python-kde3 kdepim3 srcrep:ea2b965c6714375c5b04984b9dc1f7f4-kdebase3 srcrep:ea2b965c6714375c5b04984b9dc1f7f4-kdebase3 srcrep:3a7c5e0e03ccc7bf009771b44c427695-kdegames4 srcrep:4820cd868700d8d3fdc67177fd85528c-kdeaddons3 srcrep:6884e1a3f7a8dd2a194823ce62df73eb-python-kde3 obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard/1b7482b2cf00d01 1a39eff2d5a03c3b1-kdepim3
It seems to return some kind of classification scheme intermangeled with a hash key for most cases. What I have proposed is to supply the primary repository URL the package can be redownloaded from in order to group packages by their zypp-installation source. However obs://build.suse.de/SUSE is no valid URL where I could redownload the package from.
well, the "srcrep:$SRCID-$PACKAGENAME" type entries in DISTURL are either old ones (before we did the change in OBS) or packages not built by the buildservice but by the internal autobuild system.
Current packages in Factory all have the newer type DISTURL entry and so have all packages built now in our buildservice instances. # rpm -qp --qf "%{DISTURL}\n" aaa_base-11.2-25.1.i586.rpm obs://build.opensuse.org/openSUSE:Factory/standard/6403dd6eefcf978497ed22fedecf505d- aaa_base # rpm -qp --qf "%{DISTURL}\n" aaa_base-11.1-10007.15.1.i586.rpm obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard/7e6825744b2f0ba55cdd7a35d598266f- aaa_base
the first one was built in the opensuse.org buildservice and can be downloaded via it's repo server area, so "obs://build.opensuse.org/" maps to "http://download.opensuse.org/repositories/"
the second one is an update package. "obs://build.suse.de/SUSE:openSUSE:11.1:Update:Test/standard" maps to "http://download.opensuse.org/update/11.1/" but that repo is not an output repository of the buildservice since it contains other data as well (updateinfo,deltarpms,susedata etc.) The packages are built in the internal instance mostly because of the need to be able to build updates even before a coordinated release date for example and the built packages are then processed further and end up in that update repository as they are released (at that same point in time the packages are available together with their sources in https://build.opensuse.org/project/show?project=openSUSE:11.1:Update which however is just a project to build against and not publishing sources or binaries since they are injected as I just wrote.
So while these might not be direct URLS to repositories, these still can be used to _hint_ where a package came from.
BUT: a package built in one project/repository could end up in more than one output repository available to the installer. This can be true for update repositories of several products in a product family or in a much simpler case: Think of openSUSE 11.1: The same (identical) package is available on your install media (for example a CD,DVD) and on the FTP install source http://download.opensuse.org/distribution/11.1/repo/oss/suse/ and there could be another one at http://download.opensuse.org/repositories/openSUSE:/11.1:/standard (which does not exist since it's disabled) but I guess this explains the idea.
In short: at the time of creation of the rpm, when the RPMTAGs are filled out, the package does not know yet in which (and how many) repositories it can end up. So except for really modifying the binary rpms at the time when a output repository is put together and its metadata is written (for example using createrepo) the binary rpms can't have that data as it's not known yet during build.
Actually it is not true that translating the DISTURL into a final download URI is as simple as this; lately wanted to fetch kernel-2.6.30-xen by looking up where kernel-2.6.30-default came from but found no useful information in the DISTURL-tag: DISTURL = srcrep:dcba9ce60242e255be51d5599985dc0c-kernel-default further help appreciated. -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Duncan Mac-Vicar Prett schrieb:
Elmar Stellnberger wrote:
What about simply utilizing a previously unused rpm-tag to directly determine via the rpm-header where a package came from? Then we do not need to parse the whole history just for this purpose! I have had a look at all header entries and have found a promising up to now unused candidate: RPMTAG_SOURCE
For the future RPMTAG_SOURCE could carry the Buildservice-URL a package is provided via. SOURCE = http://download.opensuse.org/repositories/KDE:/Community/openSUSE_11.1
RPMTAG_DISTRIBUTION could then no longer be complicated with the info already present in RPMTAG_ARCH, but extended with a hint like Buildservice/Core:
How do you handle mirrors in this case?
For mirrors it should not return the mirror but rather the primary main repository the mirror mirrors. It is meant as classification scheme and besides this as opportunity to redownload the package rather than as historical download URI. Consequently we desire all packages from the same primary source to hold the same URI, even if all these packages have in deed been downloaded from different mirrors and even if the zypp source they have been obtained from has been renamed, removed and added multiple times (no history analysis can fully come up to this!). -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
participants (5)
-
Adrian Schröter -
Duncan Mac-Vicar Prett -
Elmar Stellnberger -
Klaus Kaempf -
Ruediger Oertel