Am Mittwoch, 14. April 2010 15:28:09 schrieb Adrian Schröter:
Am Mittwoch, 14. April 2010 14:45:44 schrieb Michael Schroeder:
On Wed, Apr 14, 2010 at 02:43:44PM +0200, Thomas Schmidt wrote:
On 14.04.2010 14:36, Adrian Schröter wrote:
The repserver has already some code to find out if a repo is published already or not.
We could extend that and tell you already, if a package has been published or not.
So we could avoid this additional traffic and IMHO also possible area of bugs.
What do you think about that ?
I don't know. The implemented way is only a head request... Can we rely on the repservers published state? Maybe there get files removed on the public server after being published or sth. like that? We already have a published state in the buildresult, is this related?
The "published" state of the repository doesn't help at all, as you don't know which packages are the unpublished ones if the state is not "published".
Yes, the current information are not enough for this. But I think we could extend the current code, which lists all binary results of a package. The check would need to validate if the package was prepared for publish (in :repo) and if the publish happened already.
Btw, there is still the problem, that it is sort of unknown in which sub directory the package will land (i586/ or noarch/ or suse/x86_64/ or amd64/ or all/ or ...) depending on the repository mode. But the current code seems also only to guess here.
As just discussed with Michael, we see some more problems. For example .noarch.rpm files or packages where the packager is playing with the release number would not necessary the same on download.o.o. Yes, in most cases it should not matter. But when you debug some error (for example a noarch.rpm which builds differently on the architectures due to some bug) this could drive you crazy, because you may get the wrong package. It might be possible to do this check via the /published route to guarantee that the file is published and really the file on download.o.o is from the build shown in the webui. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org