> On 05/23/2013 06:09 PM, John.Florian@xxxxxxxx wrote:
> > And even though I have to give rpmbuild a tarball, I don't
> > believe it ever reuses it "as is". My understanding is that the content
> > gets extracted, processed and tarballed again.
>
> I dont know what gave you such an idea
Me neither. Perhaps the apparent slowness with large packages and/or a lack of coffee this morning.
, rpm certainly does nothing of
> the sort. The tarball is obviously extracted for building, but what ends
> up in the src.rpm is the original tarball and the patches defined in the
> spec - this is the "pristine sources" principle:
> http://rpm.org/max-rpm-snapshot/ch-rpm-philosophy.html#S1-RPM-
> PHILOSOPHY-PRISTINE-SOURCES
You are, of course, right. I actually knew that for srpms. I just tend not to think about the srpms much since for nearly all the builds I do, *I am the upstream* source so I'm really only interested in the binary rpms.
> > I'd like to see it behave more the way I expected it to when I naively
> > first started rolling my own packages. Specifically, it would be nice
> > if the %Source URI was processed intelligently to automatically retrieve
> > the content via HTTP, FTP, GIT, FILE or whatever (within reason) happens
> > to be specified there.
>
> Rpm >= 4.10 can automatically download remote sources and patches over
> http and ftp, but since there's (currently) no way to verify downloaded
> content the feature is disabled by default as its quite a security risk
> to download arbitrary content from the internet without checking
> checksums at least.
That seems sensible. I guess my biggest wish here in this sub-thread is that building rpms was more streamlined/efficient for use case such as mine where I author and package and only distribute via rpm. The current model imposes a need to self-publish tarballs, even if they only have very short life span in /tmp. If I've got a git clone with everything needed, including a spec file there, I'd like to build an rpm directly from that. I've scripted to meet my use case but it always seems quite hackish for some reason. I guess with the above knowledge about srpms, it's not as bad as first thought.
RPM is a great container/delivery system, but it definitely feels like it might be generalized more to handle both the common FOSS model and internal private uses.
PS. When I speak of large packages, I don't joke. One terrifying example is something I call "mayflower" (think early American settlers) which ships an entire livecd-tools generated image along with some magic glue which when this package is installed causes a special initrd to be generated with a dracut module for doing a swap of two livecd images. Install the mayflower rpm, reboot and you get an in-place upgrade just like that. (This is unbelievably useful if you have hundreds or more of nodes running such images in an embedded hardware.) Yeah, I forced a round peg into a very square hole, but it works beautifully. I'm both embarrassed and proud! :-)
--
John Florian
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
