dependencies page
by Karsten Wade
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
15 years, 5 months
"In Fedora" or "For Fedora", or Library versions dependency management
by Fernando Nasser
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
15 years, 6 months
news on JPackage
by Karsten Wade
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
15 years, 6 months
rpmbuilder
by David Huff
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
15 years, 6 months