Excerpts from Michael K. Johnson's message of 2014-03-20 02:44:41 +0100: > On Wed, Mar 19, 2014 at 02:51:05PM +0100, Martin Bähr wrote: > > Excerpts from Michael K. Johnson's message of 2014-03-19 11:40:22 +0100: > > > 1. rpmbuild adds functionality to invoke cvc and converts the > > > resulting build output to a standalone RPM. > > > 2. conary controls the build process, creating a spec file that > > > hands control during the build process back to conary > > > > > The second possibility could make RPM packaging > > > a lot easier, but does not create a standalone RPM. > > > > what does it create then? > > from a fedora dev perspective, if it doesn't create an rpm how is it rpm > > packaging? > Sorry, I meant doesn't build a standalone SRPM. So it couldn't > integrate into normal RPM build processes.
ah, ok, so both methods do create standalone rpms. but then i am unclear what goes in. focusing on the second, as that seems more interesting. so you mean it does not create srpms. well, that kind of makes sense. any srpm it could create would contain that conary generated spec file. obviously srpms would have to be replaced with a conary repository. as long as rpms can be created so that it is easy to host single rpms and let people deal with them in a way they are used to, because i think having to set up a conary repo to host a few packages is something that's difficult to take on. note that i am not discussing this to find solutions to these problems, but just to understand more about them, especially about the limitations that come from using conary. i am trying to figure out how a fedora developer would react to this, and what kind of questions they might have, starting with the assumption that they would like to change as little as possible at least from the user side of things. even if i won't bring this up in the talk, the more i know about it, helps me be prepared for questions from the audience, many of which will know fare more about rpm than i do at this point. so please feel free to elaborate on this and any of the other topics as much as you like. i'll pick through those one by one to gain more insight on each of them. greetings, martin. -- eKita - the online platform for your entire academic life hackerspace beijing - http://qike.info -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org BLUG secretary beijinglug.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/ _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
