Hi,
I'm about to submit tomcat-native (also known as libtcnative, tcnative) for review in Fedora, but my primary interest for it is EL-5, specifically CentOS 5.
But before doing that, I'd like to verify that it is not already available in some RHEL 5 channels and that the package won't cause problems if it's shipped in EPEL 5, if I should adjust something etc. For CentOS 5 it's fine, but I don't have a RHEL 5 box at the moment that I could use to check for possible conflicts and the like.
Is there a complete list of all binary packages included in all RHEL channels that EPEL should be compatible with available somewhere? Complete public binary repodatas (just the metadata, not packages) of binary packages included in them would be nice.
If not, could they be arranged somewhere? In the meantime, could someone verify if tomcat-native/libtcnative/tcnative is available in some RHEL 5 channel or not?
On Mon, 20 Aug 2007, Ville Skyttä wrote:
I'm about to submit tomcat-native (also known as libtcnative, tcnative) for review in Fedora, but my primary interest for it is EL-5, specifically CentOS 5.
But before doing that, I'd like to verify that it is not already available in some RHEL 5 channels and that the package won't cause problems if it's shipped in EPEL 5, if I should adjust something etc. For CentOS 5 it's fine, but I don't have a RHEL 5 box at the moment that I could use to check for possible conflicts and the like.
It won't be fine for CentOS 5 either if it is not fine for RHEL 5. CentOS also rebuilds the source packages from other RHN channels and even if they may not be available right now they may be in the future. So the same concerns hold true.
Is there a complete list of all binary packages included in all RHEL channels that EPEL should be compatible with available somewhere? Complete public binary repodatas (just the metadata, not packages) of binary packages included in them would be nice.
That would be interesting indeed. A complete list of binary packages, metadata and a list of all the SRPMs (just to verify if they all are on the mirrors and have not been mistakenly forgotten).
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On Tuesday 21 August 2007, Dag Wieers wrote:
On Mon, 20 Aug 2007, Ville Skyttä wrote:
I'm about to submit tomcat-native (also known as libtcnative, tcnative) for review in Fedora, but my primary interest for it is EL-5, specifically CentOS 5.
But before doing that, I'd like to verify that it is not already available in some RHEL 5 channels and that the package won't cause problems if it's shipped in EPEL 5, if I should adjust something etc. For CentOS 5 it's fine, but I don't have a RHEL 5 box at the moment that I could use to check for possible conflicts and the like.
It won't be fine for CentOS 5 either if it is not fine for RHEL 5. CentOS also rebuilds the source packages from other RHN channels and even if they may not be available right now they may be in the future. So the same concerns hold true.
Ok, that just amplifies the point that the information requested below seems to be critical prerequisite for inclusion of *any* package in EPEL. Steering committee, please process this request with high priority.
Is there a complete list of all binary packages included in all RHEL channels that EPEL should be compatible with available somewhere? Complete public binary repodatas (just the metadata, not packages) of binary packages included in them would be nice.
That would be interesting indeed. A complete list of binary packages, metadata and a list of all the SRPMs (just to verify if they all are on the mirrors and have not been mistakenly forgotten).
On Tue, 2007-08-21 at 15:05 +0300, Ville Skyttä wrote:
Ok, that just amplifies the point that the information requested below seems to be critical prerequisite for inclusion of *any* package in EPEL. Steering committee, please process this request with high priority.
Is there a complete list of all binary packages included in all RHEL channels that EPEL should be compatible with available somewhere? Complete public binary repodatas (just the metadata, not packages) of binary packages included in them would be nice.
There are a lot of people here with knowledge of how Red Hat works.
Is there an impediment to getting that list?
On 8/21/07, Karsten Wade kwade@redhat.com wrote:
On Tue, 2007-08-21 at 15:05 +0300, Ville Skyttä wrote:
Ok, that just amplifies the point that the information requested below seems to be critical prerequisite for inclusion of *any* package in EPEL. Steering committee, please process this request with high priority.
Is there a complete list of all binary packages included in all RHEL channels that EPEL should be compatible with available somewhere? Complete public binary repodatas (just the metadata, not packages) of binary packages included in them would be nice.
There are a lot of people here with knowledge of how Red Hat works.
Is there an impediment to getting that list?
-- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Can someone detail out what information is being looked for? Also, what channels in RHN would some of this stuff fall under. I think that tomcat and lots o' other java stuff is in some developer channels. We'll need to iron the whole thing out.
stahnma
On 8/21/07, Michael Stahnke mastahnke@gmail.com wrote:
On 8/21/07, Karsten Wade kwade@redhat.com wrote:
On Tue, 2007-08-21 at 15:05 +0300, Ville Skyttä wrote:
Ok, that just amplifies the point that the information requested below seems to be critical prerequisite for inclusion of *any* package in EPEL. Steering committee, please process this request with high priority.
Is there a complete list of all binary packages included in all RHEL channels that EPEL should be compatible with available somewhere? Complete public binary repodatas (just the metadata, not packages) of binary packages included in them would be nice.
There are a lot of people here with knowledge of how Red Hat works.
Is there an impediment to getting that list?
-- Karsten Wade ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.fedorapeople.org | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Can someone detail out what information is being looked for? Also, what channels in RHN would some of this stuff fall under. I think that tomcat and lots o' other java stuff is in some developer channels. We'll need to iron the whole thing out.
Well there is the "Extras" which contains non-FLOSS code and some kernel modules that arent in the main-line I think. The only other stuff that would be not on CentOS-4/5 that is on RHN would be the RHX channels.
On Tue, 21 Aug 2007, Stephen John Smoogen wrote:
On 8/21/07, Michael Stahnke mastahnke@gmail.com wrote:
On 8/21/07, Karsten Wade kwade@redhat.com wrote:
On Tue, 2007-08-21 at 15:05 +0300, Ville Skyttä wrote:
Ok, that just amplifies the point that the information requested below seems to be critical prerequisite for inclusion of *any* package in EPEL. Steering committee, please process this request with high priority.
Is there a complete list of all binary packages included in all RHEL channels that EPEL should be compatible with available somewhere? Complete public binary repodatas (just the metadata, not packages) of binary packages included in them would be nice.
There are a lot of people here with knowledge of how Red Hat works.
Is there an impediment to getting that list?
Can someone detail out what information is being looked for? Also, what channels in RHN would some of this stuff fall under. I think that tomcat and lots o' other java stuff is in some developer channels. We'll need to iron the whole thing out.
Well there is the "Extras" which contains non-FLOSS code and some kernel modules that arent in the main-line I think. The only other stuff that would be not on CentOS-4/5 that is on RHN would be the RHX channels.
I think there's more than just RHX/Extras. Everything that is in RHN and that is not available from ftp.redhat.com in RPM or SRPM format. There are beta-channels that are not offered as SRPM afaik.
But it's hard to list things that you don't know exist :) Someone with full RHN access could simply verify for himself.
Also, it would be useful to have everything that cannot be distributed available in nosrc format as well.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]
On 8/21/07, Dag Wieers dag@wieers.com wrote:
On Tue, 21 Aug 2007, Stephen John Smoogen wrote:
On 8/21/07, Michael Stahnke mastahnke@gmail.com wrote:
On 8/21/07, Karsten Wade kwade@redhat.com wrote:
On Tue, 2007-08-21 at 15:05 +0300, Ville Skyttä wrote:
Ok, that just amplifies the point that the information requested below seems to be critical prerequisite for inclusion of *any* package in EPEL. Steering committee, please process this request with high priority.
> Is there a complete list of all binary packages included in all RHEL > channels that EPEL should be compatible with available somewhere? > Complete public binary repodatas (just the metadata, not packages) of > binary packages included in them would be nice.
There are a lot of people here with knowledge of how Red Hat works.
Is there an impediment to getting that list?
Can someone detail out what information is being looked for? Also, what channels in RHN would some of this stuff fall under. I think that tomcat and lots o' other java stuff is in some developer channels. We'll need to iron the whole thing out.
Well there is the "Extras" which contains non-FLOSS code and some kernel modules that arent in the main-line I think. The only other stuff that would be not on CentOS-4/5 that is on RHN would be the RHX channels.
I think there's more than just RHX/Extras. Everything that is in RHN and that is not available from ftp.redhat.com in RPM or SRPM format. There are beta-channels that are not offered as SRPM afaik.
But it's hard to list things that you don't know exist :) Someone with full RHN access could simply verify for himself.
Also, it would be useful to have everything that cannot be distributed available in nosrc format as well.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
I'll check my RHN account tomorrow. We have many channels, not sure if it's all of them or not. I will start making a list and post here.
stahnma
On Tue, Aug 21, 2007 at 06:20:47PM -0500, Michael Stahnke wrote:
Can someone detail out what information is being looked for? Also, what channels in RHN would some of this stuff fall under. I think that tomcat and lots o' other java stuff is in some developer channels. We'll need to iron the whole thing out.
Tomcat is a standard part of RHEL5 and thus in the regular channels, like much other Java stuff, that was formerly (pre-RHEL5) known as the "Red Hat Application Server".
On Wednesday 22 August 2007, Jos Vos wrote:
On Tue, Aug 21, 2007 at 06:20:47PM -0500, Michael Stahnke wrote:
Can someone detail out what information is being looked for? Also, what channels in RHN would some of this stuff fall under. I think that tomcat and lots o' other java stuff is in some developer channels. We'll need to iron the whole thing out.
Tomcat is a standard part of RHEL5 and thus in the regular channels, like much other Java stuff, that was formerly (pre-RHEL5) known as the "Red Hat Application Server".
tomcat is also in Fedora, but that's not what I'm talking about. What I'm ready to submit for review is the native APR-based connector, tomcat-native (also known as tcnative, maybe libtcnative).
http://tomcat.apache.org/tomcat-6.0-doc/apr.html http://archive.apache.org/dist/tomcat/tomcat-connectors/native/
For this particular case, I guess it suffices to know whether there are any packages that contain a file named libtcnative-1.so in any RHEL 5 channels.
On 8/22/07, Ville Skyttä ville.skytta@iki.fi wrote:
On Wednesday 22 August 2007, Jos Vos wrote:
On Tue, Aug 21, 2007 at 06:20:47PM -0500, Michael Stahnke wrote:
Can someone detail out what information is being looked for? Also, what channels in RHN would some of this stuff fall under. I think that tomcat and lots o' other java stuff is in some developer channels. We'll need to iron the whole thing out.
Tomcat is a standard part of RHEL5 and thus in the regular channels, like much other Java stuff, that was formerly (pre-RHEL5) known as the "Red Hat Application Server".
tomcat is also in Fedora, but that's not what I'm talking about. What I'm ready to submit for review is the native APR-based connector, tomcat-native (also known as tcnative, maybe libtcnative).
http://tomcat.apache.org/tomcat-6.0-doc/apr.html http://archive.apache.org/dist/tomcat/tomcat-connectors/native/
For this particular case, I guess it suffices to know whether there are any packages that contain a file named libtcnative-1.so in any RHEL 5 channels.
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
I've added this topic to today's EPEL SIG.
stahnma
I haven't forgotten about this topic, but I am still at a loss for direction toward a solution. I can use the RHN API to pull in a lot of information about RHEL channels and such, but there are 400+ channels in RHN, and virtually no metadata. I suppose the metadata could somehow be derived, but that is a moving target.
I want to understand the total process before we dive in and try to solve the problem. Right now the problem from what I understand is:
Does an RHN channel already provide file : /usr/lib/foo ?
Are there other problems to tackle here? What about obsoleting an EL/RHN package? Is that bad?
stahnma
On 26.08.2007 19:56, Michael Stahnke wrote:
I haven't forgotten about this topic, but I am still at a loss for direction toward a solution. I can use the RHN API to pull in a lot of information about RHEL channels and such, but there are 400+ channels in RHN, and virtually no metadata. I suppose the metadata could somehow be derived, but that is a moving target.
I think the point got mentioned in a meeting a bit, but not further discussed:
Why can't we simply run a small script on one or two (RHEL5Desktop and RHEL5Server) machines somewhere that just write the informations into some files and uploads those somewhere?
That way we might not provide all the data people might be interested it, but a package-list (which would be a good start) and some other stuff afaics should be possible, which is better than nothing.
CU knurd
On 8/27/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 26.08.2007 19:56, Michael Stahnke wrote:
I haven't forgotten about this topic, but I am still at a loss for direction toward a solution. I can use the RHN API to pull in a lot of information about RHEL channels and such, but there are 400+ channels in RHN, and virtually no metadata. I suppose the metadata could somehow be derived, but that is a moving target.
I think the point got mentioned in a meeting a bit, but not further discussed:
Why can't we simply run a small script on one or two (RHEL5Desktop and RHEL5Server) machines somewhere that just write the informations into some files and uploads those somewhere?
That way we might not provide all the data people might be interested it, but a package-list (which would be a good start) and some other stuff afaics should be possible, which is better than nothing.
Do you need a listing for the layered products as well, or just the base/extra/supplementary RHEL channels?
On Monday 27 August 2007, Kyle Gonzales wrote:
On 8/27/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Why can't we simply run a small script on one or two (RHEL5Desktop and RHEL5Server) machines somewhere that just write the informations into some files and uploads those somewhere?
That way we might not provide all the data people might be interested it, but a package-list (which would be a good start) and some other stuff afaics should be possible, which is better than nothing.
Do you need a listing for the layered products as well, or just the base/extra/supplementary RHEL channels?
I think the EPEL project needs to decide, enumerate and document the exact channels, derived distributions etc it attempts to be compatible with first. The answer to the above question would then be those channels etc.
On 8/27/07, Ville Skyttä ville.skytta@iki.fi wrote:
On Monday 27 August 2007, Kyle Gonzales wrote:
On 8/27/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Why can't we simply run a small script on one or two (RHEL5Desktop and RHEL5Server) machines somewhere that just write the informations into some files and uploads those somewhere?
That way we might not provide all the data people might be interested it, but a package-list (which would be a good start) and some other stuff afaics should be possible, which is better than nothing.
Do you need a listing for the layered products as well, or just the base/extra/supplementary RHEL channels?
I think the EPEL project needs to decide, enumerate and document the exact channels, derived distributions etc it attempts to be compatible with first. The answer to the above question would then be those channels etc.
Then once the project gets this info, I should be able to help with this information.
Ville Skyttä wrote:
On Monday 27 August 2007, Kyle Gonzales wrote:
On 8/27/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Why can't we simply run a small script on one or two (RHEL5Desktop and RHEL5Server) machines somewhere that just write the informations into some files and uploads those somewhere?
That way we might not provide all the data people might be interested it, but a package-list (which would be a good start) and some other stuff afaics should be possible, which is better than nothing.
Do you need a listing for the layered products as well, or just the base/extra/supplementary RHEL channels?
I think the EPEL project needs to decide, enumerate and document the exact channels, derived distributions etc it attempts to be compatible with first. The answer to the above question would then be those channels etc.
Personally I think documenting these processes is a lot of work with questional benefit. It seems to me more logical to be reactive to this. When something comes up that is a conflict, remove / fix it in epel. Trying to write and maintain a script that monitors two moving targets is bound to be buggy / hard to verify.
-Mike
On Monday 27 August 2007, Mike McGrath wrote:
Personally I think documenting these processes is a lot of work with questional benefit. It seems to me more logical to be reactive to this.
I'm afraid I'll have to disagree here and would not be comfortable with using packages from or seriously contributing to such a project. Mileages vary, of course, but I'd be surprised if it were just me.
One Scenario: work hard to produce a great package of something popular and complex, succeed, get it through the review process, ship it in EPEL. Months pass, users are happy, and build things on top of the EPEL package and its configuration. Then, someone finds out that there's a conflict/unwanted upgrade or something like that problem with the package and something in some channel or derivative distro.
I can't come up with a good way to react to this kind of a situation without breaking something, and just throwing things out there to see if something breaks is not what I'd expect from a project like EPEL. The _best_ case is that people report the problem and the reactive fix will "only" result in wasted packager/maintainer/reviewer resources.
When something comes up that is a conflict, remove / fix it in epel.
Conflicts are kind of easy as the probability of damage done to existing end user installations is pretty low because the package didn't actually get installed, but unwanted and incompatible upgrades which do get installed and start to cause problems afterwards are not.
Ville Skyttä wrote:
On Monday 27 August 2007, Mike McGrath wrote:
Personally I think documenting these processes is a lot of work with questional benefit. It seems to me more logical to be reactive to this.
I'm afraid I'll have to disagree here and would not be comfortable with using packages from or seriously contributing to such a project. Mileages vary, of course, but I'd be surprised if it were just me.
One Scenario: work hard to produce a great package of something popular and complex, succeed, get it through the review process, ship it in EPEL. Months pass, users are happy, and build things on top of the EPEL package and its configuration. Then, someone finds out that there's a conflict/unwanted upgrade or something like that problem with the package and something in some channel or derivative distro.
I can't come up with a good way to react to this kind of a situation without breaking something, and just throwing things out there to see if something breaks is not what I'd expect from a project like EPEL. The _best_ case is that people report the problem and the reactive fix will "only" result in wasted packager/maintainer/reviewer resources.
Exact same thing happens if RH decides to include it in an update.
When something comes up that is a conflict, remove / fix it in epel.
Conflicts are kind of easy as the probability of damage done to existing end user installations is pretty low because the package didn't actually get installed, but unwanted and incompatible upgrades which do get installed and start to cause problems afterwards are not.
I'm just saying that trying to put strict guidelines/lists around something that is very murky requires a lot of effort and the outcome is bound to be unreliable. The fact is what RH does or does not decide to ship is up to them and it is a completely unpredictable unordered process which we are trying to bring order to. That said, if someone wants to do the work and thinks they can make it reliable, have at it :)
-Mike
On Mon, 2007-08-27 at 16:05 -0500, Mike McGrath wrote:
I'm just saying that trying to put strict guidelines/lists around something that is very murky requires a lot of effort and the outcome is bound to be unreliable. The fact is what RH does or does not decide to ship is up to them and it is a completely unpredictable unordered process which we are trying to bring order to. That said, if someone wants to do the work and thinks they can make it reliable, have at it :)
I haven't seen any indication from any product managers that they intend to ignore what is happening in EPEL when they decide what goes into the package sets. OTOH, we don't have enough people who are communicating between the groups.
How changing of a creature is it really, when we're talking about the past? How many new-to-the-repo packages are added during a RHEL update? How about for a layered product? Isn't this just a few dozen or so lists that don't change once set?
Anyone know someone in Product Management who wants to help the communication bridge?
- Karsten
On Mon, 2007-08-27 at 14:54 -0400, Kyle Gonzales wrote:
Do you need a listing for the layered products as well, or just the base/extra/supplementary RHEL channels?
We need layered products as well.
- Karsten
epel-devel@lists.fedoraproject.org
-
Dag Wieers -
Jos Vos -
Karsten Wade -
Kyle Gonzales -
Michael Stahnke -
Mike McGrath -
Stephen John Smoogen -
Thorsten Leemhuis -
Ville Skyttä