On Mon, 2007-02-26 at 13:53 -0300, Horst H. von Brand wrote: > Hans de Goede <j.w.r.degoede@xxxxxx> wrote: > > Warren Togami wrote: > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 > > > > > > It appears that a few folks want sdcc, but do the packaging standards > > > for cross compilers and the concern about names being dropped into > > > /usr/bin should be solved first? > > > > > [...] > > > Since Ralf and I agree for 99.9% on my proposal, this really is > > almost done. The only thing which I want discussed in a wider > > audience / need more input in is the SRPM issue, quoting from my > > original mail: > > "The SRPMS for all these packages will most of the time contain the > > exact same tarbals as the native binutils / gcc / libs > > > > Possible solutions: > > a) Live with the extra diskspace / bandwidth cost this induces upon > > our mirrors > > b) *** Warning dirty hack *** > > Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep > > and if it isn't there bail with a message howto get the tarbal > > from the srpms for the native packages. We can use the sources > > file and the look-aside cache to make the test for the tarbal > > succeed on the buildsys. Advantages: saves tons of diskspace. > > Disadvantage: slight inconvienience for people trying to rebuild > > the srpm's manually. Large inconvienience for people doing > > automated rebuilds (aurora for example) > > > > I honestly don't know what todo here. I kinda like solution b), > > except for the pain it causes to aurora and possible others." > > You can build nosrc.rpms, by just stating in the .spec, e.g.: We've been using this approach for the rtems toolchains for years. In practice, this was more hassle than it had helped. The real show stopper which finally broke it was mock. It doesn't support nosrc.rpm. Ralf -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
