Software Management call for RFEs

[John.Florian at dart.biz]

> From: pmatilai at laiskiainen.org
> On 05/23/2013 06:09 PM, John.Florian at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130523/d921e07a/attachment.html>