Hi Martin We have not spoken before and I haven't contributed much to date! but the intention is there..
There are a couple of key points I think you can add w.r.t. Conary. 1. the namespace labeling; this is hugely important. 2. System closure. So 2. you have kind of mentioned it anyway but we use it from an "app dev's" perspective to close out the application at the system level rather than just the application level. What I mean by that is, suppose I am building an app like JIRA say. I can set up my maven builds to close (resolve deps) for the application, but it will also have system deps like graphviz, httpd, tomcat etc.. We use Conary (encapsulated for RHEL5/6) to extend this 'closure' by building out an appliance around our applications. I have not discovered any other tool that can do this 'deep dependency' resolution by introspection. The ability of Conary to find what fulfills #!, .so deps etc is really really powerful. Bringing that to Fedora and I presume RHEL7 will allow for greater automation of the build pipeline and greater assurance in application deployment. This will surely differentiate F20 and drive up adoption. As an example simply encapsulating the Oracle JDK throws up the fact that they ship JavaFX libs. These libs require shared object libraries that are not provided by RedHat.. yet the RPM installs these hanging libs.. Conary fails the build because they are unfulfilled. We have forced Oracle to add instructions on how to remove JavaFX which they have added to their release notes. Maybe the JDK could be used as a worked example. Yours Phil On 2 April 2014 04:18, Martin Bähr <[email protected]>wrote: > why conary is interesting in itself is a separate topic that i'd like to > frame > more as "why do we want to use conary on top of fedora instead of just > using > fedora as it is" > > this should not be about conary features. but about benefits that come > from our > work to fedora as a whole, even if they don't use conary: > > here is what i have so far: > > * the process finds bugs in fedora and fedora packages that we report back. > we could use this on rawhide to test packages before they are released. > > * conary finds more dependencies and can ensure that all dependencies are > met. > these can be reported to improve fedora packages. > > * conary keeps all packages in revision control, so every version of every > package released will remain available for the future. this helps server > users who need to downgrade individual packages after an upgrade broke > their > server. (this issue is currently being discussed in the Fedora Server WG) > > any others? > > can we make a list of issues reported? > > mkj: could you possibly share some email conversations you had about bugs > you found. > including current fedora but also centOS since some issues there may have > made > it into fedora as well. you can send that to me privately. > i'd like to make a picture of things reported. and what impact that had. > not > really listing them in the talk, but give an overview of maybe how many > issues > were found and what classes of issues those were and possibly mention an > example or two. > > 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 _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
