Mailinglist Archive: opensuse-softwaremgmt (17 mails)

[Elmar Stellnberger <estellnb@xxxxxxxx>]

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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-softwaremgmt+help@xxxxxxxxxxxx