Mailinglist Archive: opensuse-factory (837 mails)

< Previous Next >
Re: [opensuse-factory] New policy proposal for Factory: Make source of tar balls trackable
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Mon, 21 Mar 2011 12:42:53 +0100
  • Message-id: <1392155.FYQUZHM6X1@scherben>
Am Montag, 21. März 2011, 12:06:04 schrieb Sascha Peilicke:
On Monday 21 March 2011 11:40:10 Ludwig Nussel wrote:
Sascha Peilicke wrote:
On Monday 21 March 2011 11:25:06 Richard Guenther wrote:
On Mon, 21 Mar 2011, Adrian Schröter wrote:
I like to propose a new policy for Factory regarding our package
source handling with the goal that our package sources are
upgradable, modifyable and trustable by any other developer.

Please find my proposal here:

http://lizards.opensuse.org/2011/03/21/policy-proposal-for-factory-ma
ke-s ource-of-tar-balls-trackable/

And please drop some comments as reply to this mail :)

The use of source services makes the build process less transparent
(how do you build such with just rpmbuild? Build once in OBS and then
download a source rpm?). Why not just provide tarball URL and MD5/SHA
checksum in the rpm spec file? I really do not like adding other
non-standard metadata ontop of what we already have.

Actually, this is what I'd like to see too. However, AFAIK the
download_url service already uses the URL found in the Source tag.
Having that info directly in the spec file seems sanest:

Source0: http://foo.com/bar.tgz
Source0-MD5: 1234567
Source0-SHA1: 1234567

RPM doesn't like unknown tags though. I'm not sure how the chances
are to get a patch accepted that allows e.g. a X-vendor prefix.
Fedora voids an rpm patch by having a separate file 'sources' that
lists the file names and their check sums.
Or, as Michael suggested, one could use those RPM notations:

#!Source0-MD5: 1234

or

#!SourceChecksum0: md5(1234)

Yes, but this would be an additional check IMHO.

It does not make much sense to track MD5 sums here IMHO, because that is
also done anyway in the source history. But SHA256 or GPG key validation
would make sense, if the upstream project has reliable sources.

Esp. when we would build up a pool of trusted GPG keys already (where we
validated that they come from upstream projects).

bye
adrian

--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian@xxxxxxx

--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >