hi, the following is what i think is good enough to submit as a talk proposal. if you have any suggestions please don't hesitate to comment. the submission deadline is 24 hours from the time of this email.
session name: "repackaging fedora with conary" (anyone have a better title?) abstract: In this talk we will share the current work of the foresight linux project to rebase the foresight distribution on top of fedora. Foresight is a distribution with rolling releases using the conary packaging toolchain. In fl:1 and fl:2 we built the distribution on top of rpath, who also developed conary. For fl:3, the next major incarnation of foresight we are rebasing on top of fedora. To do this, we are importing all of f20 into a conary repository and we are then building our own distribution on top of this collection. This enables us to effectively use fedora with our own packaging toolchain. Then, having done this, we have the opportunity to explore whether in doing so we have solved problems that have plagued Fedora. For example, while many people upgrade Fedora regularly without problems, there are also many horror stories of fedup breaking people's systems. Many of the kinds of breakage that show up are things that Conary could address. Among those are more complete deps and dep-complete update jobs often avoiding the "broken screensaver" problem, and groups allowing a more precise migration that avoids leaving straggling bits that create untested situations that break. We have not been the one experiencing these problems, so we can't say for sure. We just know that we've been able to maintain a rolling distro across major updates for years (though we quit updating gnome when gnome3 showed up...) and so it's worth trying. It might be that if people trusted Fedora updates more, they would update more, which would be good for Fedora. It's a distraction when people complain about the short maintenance lifetime. Can we make that better? Then Foresight becomes a rolling remix, not only useful on its own, but an opportunity and context in which to demonstrate whether or not Conary can make the Fedora base bits roll forward with fewer update failures. We've already found packaging bugs in the release just from trying to import into Conary. We expect to find more. That has typically happened during Conary imports of RPM distributions. If we import the beta releases of Fedora, we can find bugs before they hit users, and the kinds of bugs Conary finds are usually the ones that are easy to fix, "low hanging fruit" that can really contribute to fit and finish. There was some interest last year in whether the conary build process could make it easier to build RPMs, but there was really not enough interest to get enough people involved to make it happen. If interest rises this topic could be revisited. (i rewrote the first part and then copied the rest with slight modifications. thanks mkj for pretty much writing this for me!) outline: The talk will cover the following points: * Short introduction to foresight and conary * What are we doing with fedora? * Why is this interesting for the fedora community? * Enabling Fedora users to consume Fedora using a rolling model. * Demonstrating a new way to build a Fedora remix, one that takes advantage of the rolling model and helps the remixes stay current. * Contributing to upstream quality by catching certain classes of bugs prior to release. * Using Conary's extensive package build automation to make it easier to build better packages for Fedora. 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
