> From: pmati...@laiskiainen.org > On 05/23/2013 06:09 PM, john.flor...@dart.biz 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
