Need some help

As a lot of people know I am the one that is generating the updated Livecds that are floating around.

I need an automated way of pulling the srpms and creating an srpm iso from livecds

a) yes i could extract the rpmlist from the livecd.iso afterI create the iso but that is time consuming when you are talking about 8 isos per release

b) I dont want to maintain a snapshot ofthe updates rpm everytime i create new images

What i am thinking is creating a kickstart file that imports all the fedora-livecd-<Desktop Environment>.ks  (Where <Desktop Environment>==Desktop, KDE, XFCE, LXDE)

and using some tool pull all the SRPMS at the sametime and createing a updates SRPm.iso.

Issues: updates repos are ever changing so we have a small window of time to pull the SRPMS

Help so I can keep creating updated LIvecds.

Advertisements

4 Comments

Filed under Fedora

4 responses to “Need some help

  1. mdomsch

    https://fedorahosted.org/correspondingsource/browser/liveiso_srpm_list
    will extract the SRPM list from your live ISO, so it’s not horribly time-consuming…

  2. Ben Williams

    matt thats the problem i dont want to exactly the list if i can keep from it, i want to create one SRPM.iso from all 4 Desktop Environment ks in one pass instead of having to combine from every live.iso
    and also we are back to the time issue again about updates repo changing
    (make livecd, use this script, combine results and the updates repo has changed.)

    • mdomsch

      For doing it in one pass, one could easily adjust the script to take multiple ISO files as arguments, and let it do the rpmlist, uniq, and output a sorted list across the whole lot. If that would be useful, I’m sure it’s only a few lines of code, would probably take 10 minutes.

      As for the problem of needing to download the SRPMS which might disappear, the only easy answer I have is to have a private mirror of the tree(s) you’re composing from, complete with the corresponding SRPMs which are in the tree, so you’re not pulling from a mirror (which could get updated) during your compose process. It’s also possible to generate a SRPM from a given package tag in git now, and the package tags are of common format, so that wouldn’t be as difficult, but I prefer to include the SRPMs that were actually used to build the binary, which should be the same as the git tag, but with enough back-end shenanigans, could be different. This means either grabbing the SRPM from koji, or from the mirror before you begin the compose. There’s a “srpm-generator” script in the correspondingsource repo that could get srpms from CVS tags back in the day. It should be a similar process for fedpkg/git now.

      When I’ve done my ftbfs runs, this is what I do. I have a separate mirror of the content to be built, which is then frozen for the duration of the build process. It’s ~150GB for a single release, excluding debuginfo would cut that down by at least 50GB – not small, but not insurmountable either.

  3. oliverhenshaw

    Perhaps some kind of gnarly squid configuration would do it? Like (the seemingly abandoned) IntelligentMirror. I’m not sure how much work it would take but I’m wondering if you could configure it to lookup the srpm for the .rpms it’s downloading and cache them too.

    I’ve been idly wondering how to do something like this myself, with the aim of gathering all the debuginfo rpms for a kickstart install in order to create a local debugfs/retraceserver arrangement. It’s doable with a private mirror, as suggested by mdomsch, but that feels like overkill when you’re only interested in a small fraction of available packages (and only the install repo packages that aren’t in updates).

    Problem is you can’t know what packages you’re going to install until you do it and the update repo might have changed by the time you perform a second transaction.

    So perhaps the answer is to download the srpms first: you could download the rpm + srpm together in a single transaction, cache them (either from livecd-creator or IntelligentMirror); create a local repo if necessary; and finally create the regular isos. I think you can do most of that by stringing together existing tools, it’s just the first step that’s tricky. Maybe combine all the kickstart files as you suggest, and write a yum plugin like yum-plugin-auto-update-debug-info to pull in the corresponding srpms when you create the combined live image. Then extract the sources to a .srpm iso.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s