Build control-center in mock fail

[Nico Kadel-Garcia]

On Thu, May 16, 2013 at 11:38 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Thu, 2013-05-16 at 22:48 -0400, Nico Kadel-Garcia wrote:
>> On Thu, May 9, 2013 at 12:12 AM, Rahul Sundaram <metherid at gmail.com> wrote:
>> > Hi
>> >
>> >
>> > On Thu, May 9, 2013 at 12:04 AM, Adam Williamson wrote:
>> >>
>> >>
>> >>
>> >> Yes, I know that, thanks. I didn't ask for a lecture, but whether this
>> >> was actually written down in the guidelines somewhere.
>> >
>> >
>> > It is not written down as policy and since the tools themselves enforce
>> > this, I don't think it has been needed
>> >
>> > Rahul
>>
>> Which tool enforces this? Unless the toolkit for the build
>> environments is completely isolated from the Internet and uses only
>> disk access or local VLAN for it's access to source file repositories,
>> this can be very difficult to enforce.
>
> It is, as mentioned elsewhere in the thread. The build hosts do not have
> outside network access.

[ Sorry for the late reply, I've been at a family funeral this week. ]

That's very specific to the Fedora build environment. Difficult to
replicate in the field without a huge local build structure! And
enforced by a specific build environment is nowhere near the same
thing as "mandated by published policy" to help SRPM builders know how
they should plan their work.

>> But I continue to
>> run across Java based SRPM's that use "maven" and wind up with broken
>> URL's or insufficiently specific URL's that just grab the latest
>> modules from their relevant upstream repo.
>
> In Fedora's build system the source tarballs aren't ever 'automagically'
> pulled from the URL specified in the spec file, so it can be utterly and
> complete incorrect without any obvious consequences. Though by policy,
> it's supposed to be valid and correct.

Completely agreed, but irrelevant to the "maven" problem I just
described. I've caught perl package builders doing it, too. The
"%build" part of their software, or tools like "maven", automatically
pull in dependencies from arbitrary external locations without ever
listing the source bundles in the .spec files. Good package mantainers
normally deal with this by using the "maven-jpp" command, which
correctly refuses to pull down uninstalled dependencies. But new RPM
builders have little guidance to avoid this pitfall.

>> It would make my life easier to have a stated policy I can point
>> packagers to in the wide world. Please?
>
> Fedora's policies only apply to packages that are part of Fedora in any
> case, so I'm not sure why you think people who are packaging outside of
> the Fedora repositories would pay attention to a Fedora policy, and we
> can't really set policies for anyone else...:)

Well, no. But they're good policies, and it would help me to have them
be explicit so I can point to them as reference guidelines, rather
than relying on the koji build system to enforce an entirely unstated
policy.