On Wednesday, December 16, 2015 09:53:25 AM Adam Williamson wrote: > On Wed, 2015-12-16 at 09:23 -0800, Brian C. Lane wrote: > > > surprise. The surprise was the output that we got. In Release > > > engineering we want the tooling to make the artifact as we are going to > > > ship it. This means that someone running the tool at home can make the > > > same thing as what we make. I was expecting for output something along > > > the lines of Fedora-Live- > > > Workstation-x86_64-rawhide-20151215.iso which is what we get from > > > livecd- creator. Instead of just an iso what I got was a tree > > > > Remember that this is not livecd-creator, and it was not designed to > > give you the same output. > > Well, yes, but also, it's supposed to be livecd-creator's replacement, > and it's supposed to perform the same role. Surely one of its #1 goals > should be "to produce what release engineering wants it to produce", > since that's probably its most critical role. If releng is telling you > its output is not what they want, that seems like something to > consider. anyone at home making livecds's or people doing remixes will be expecting the same output as livecd-creator > > > where the only thing that we will ship is images/boot.iso but we will > > > have to do manipulation of the tree to keep what we want and name it > > > correctly and discard all the extra bits. this means that every use > > > that makes livecds will need to write tooling to extract the boot.iso, > > > rename it and discard the extra bits. > > > > Don't you already have to do that with the new lmc koji code to grab the > > output from the run inside mock? I really don't see the need to add yet > > this to lmc when your code can easily move the boot.iso to the final > > location/name and remove the intermediate directory. There are many cases where people make livecds without koji. each one of them needs to write something? > You didn't provide any response to dgilmore's objection to this design: > that anyone else using lmc would have to recreate that work. Obviously > not everyone who wants to build a live image for testing has a Koji > instance they can run it through. > > > > given > > > http://dl.fedoraproject.org/pub/fedora/linux/releases/23/Live/x86_64/ > > > as an example of how we ship live media it is not a great thing to have > > > to do. I strongly feel that a small piece of additional code in > > > livemedia-creator to correctly name the iso given that there is a > > > --image-name flag is reasonable and will save every person that makes > > > livemedia from having to rewrite basically the same function, or us > > > just writing a wrapper around livemedia- creator to do so. > > > > lmc uses lorax to create the iso output, which it why it looks very much > > like a boot.iso tree. I want to minimize differences from lorax as much > > as possible. > > But presumably you also want a tool that produces what its users > actually want. As someone who uses livecd-creator regularly, I want > what dgilmore wants: a live ISO file. I don't want all that other > stuff. Naming is a bit trickier, but it certainly seems reasonable to > at least provide the ability to choose the output file name with a > parameter (as livecd-creator did). anyone that respins fedora lives's either adding updates, or making a remix adding things we can not ship is going to want what I am asking for and will not have koji and will have to re-implement something to get the output needed. There are many use cases outside of releng that wants to make a livecd and just a livecd. There is nothing wrong with code reuse. I do not see how we can ship what is produced even if we decide that some of the extra stuff is useful. we can not ship 20 isos called boot.iso. people regularly grab isos from different parts of the tree and sync them to a common directory. Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
