isv-sig September 2008

isv-sig@lists.fedoraproject.org

6 participants
5 discussions

dependencies page
by Karsten Wade 06 Oct '08

06 Oct '08

This page is a good example ... https://fedoraproject.org/wiki/Alfresco ... of what we are going to need for all of you. I'm planning to send out an email to the general developers list (fedora-devel-list), inviting packagers who are interested in ISV software to assist with the packaging efforts. They benefit from the dependency list. Getting out this list of dependencies is the first step[1] in getting software packaged. I encourage you to post whatever you have so far to the wiki so that others can read and assist.[2] If you need any assistance with the wiki, please contact me. Using the general format of https://fedoraproject.org/wiki/Vendor_Name is a good place to start gathering content. Let us know when you get something posted! Thanks - Karsten [1] https://fedoraproject.org/wiki/SIGs/ISV#What_next.3F [2] The work on the Alfresco page was a back-and-forth effort between subject matter experts of Alfresco, Fedora, and Java. There is expertise that can help when the details are visible to them. -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41

4 6

"In Fedora" or "For Fedora", or Library versions dependency management
by Fernando Nasser 17 Sep '08

17 Sep '08

Hi folks, We are preparing a set of JBoss AS 4.2.x RPMs _for_ Fedora. I say 'for' because we have a huge (hundreds) dependency set and some of the things are not suitable for Fedora. We've been working in reducing this set, solving problems but that will take a couple of years at least, and will probably be for an AS 5 version, never for the 4.2.x as there is no way to influence that upstream at this stage. So we decided to have a separate repository that people can subscribe their systems too and install a jbossas 4.2.x RPM with the dependencies that are not on Fedora etc. Another problem that is hitting us, and this is the main reason of this message, is that the versions of some packages that are in Fedora base are not compatible with ours stuff. An App Server has to pass TCK certification and has too many component interactions end up requiring very specific versions of the libraries. We are having to add some hacks to our package to work around that. Some cases we can solve by upgrading the package in the next Fedora base, *IF* that dosen't break something else that depends on those libraries and is in Fedora already. Some others we will keep bugging JBoss AS maintainers to upgrade in some new release. Some we have a 'versioned' package that installs in parallel. Other just can't be helped. This problem of conflicts of dependency version requirements happens even between our products. We have created a scoreboard with versions of the libraries we need so we could negotiate, among all projects, the versions we will be use in ALL products. But it is not easy, there are cases which are very difficult to solve -- you either break one or the other, backporting is difficult etc. My point is, the more packages we add to the Fedora base the worse it will be for us to agree on the versions of these. So this would indicate that the "for Fedora", as opposed to "in Fedora" approach should be considered by all. On the other hand, each of us having a different set of libraries in our own repositories will make it difficult for people wanting to install more than one. A solution for this would be for us to foresee possible cases where interoperability is desired and work out the dependency problems just between those ISV products involved. Another thing, even if we go to a "in Fedora" as the preferred method, we still can use the "for Fedora" approach as a intermediate state, before all dependencies needed by some product exist in Fedora. One of our possible solutions to make our JBoss AS RPM set available is release it in JPackage.org. They have mirrored repositories and there are distro specific repos, in addition to the generic repos, so our modifications for Fedora can be uploaded to their fedora-9 repo. Of course, if we all decide to make things available from JPackage, the dependency conflict will move there. But JPackage wants to have a 'base' repo with additional (and optional) repos for some major components like App Servers, so one can decide if they want, for instance, JOnAS or JBoss, and get the appropriate dependencies. This added to the yum priority plugin turns in a very flexible setup. The above looks more like a brain dump, sorry. I just came back from vacations and I am traveling for a meeting next week, so time is scarce. Regards to all, Fernando

2 3

news on JPackage
by Karsten Wade 16 Sep '08

16 Sep '08

We've been hunting down answers on how to work across JPackage and Fedora. The news is mixed with a bright future. Your help now makes the bright future more obtainable. The reality is that while JPackage and Fedora packages are very alike and the packing rules are more closely aligned, there is no automagic to make it easier to maintain one package across both systems. By acting now within both communities, our up front work can help support a goal of minimizing or removing barriers between the two package repositories. Fedora requires everything it needs to build to be entirely in the build system. It cannot rely upon outside repositories. This is a fundamental design decision. That means that nearly the same package from JPackage must be rebuilt in the Fedora system. The goal is to find a way to make moving packages between the systems fully transparent. This cuts down significantly on package maintainers work while allowing JPackage to service the wider RPM audience. Jesse Keating, Fedora Release Engineer, is one person leading this effort. It sounds as if help is still needed within Fedora and JPackage to move this ahead. There are still decisions to be made on how to proceed, we may influence that by acting within both communities. In the meantime, the best process to follow is this: 1. Get Java libraries working in JPackage 2. Once there, import those packages in to Fedora - This will be much faster with most of the work already done from the JPackage review 3. Once forked, you need to update packages in both locations, syncing changes back/forth If we can make a custom of doing these practices, it helps make the infrastructure level changes easier to occur. Let me know your thoughts/questions on this, I'd like to codify this on the wiki as our policy for ISVs. - Karsten -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41

2 1

Java Packaging and repacking jars
by Bryan Kearney 16 Sep '08

16 Sep '08

I know that this issue comes up alot when packaging java apps. There is a discussion [1] over on fedora-java that folks may want to watch or participate in on this. -- bk [1]https://www.redhat.com/archives/fedora-devel-java-list/2008-September/msg…

1 0

rpmbuilder
by David Huff 10 Sep '08

10 Sep '08

I saw this project mentioned on the Fedora-dev list, and found it interesting. This is something the RHX had talked about and thought would be very useful for ISV's. The project seems to be in its infancy and is looking for volunteers. https://fedorahosted.org/rpmbuilder -D

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

isv-sig September 2008