Please forgive a possible repeat post. I did not see this in the archives so was not sure if it had gotten sent.
With the differences between EL-6 architectures we are finding that we need to build things for PPC or i386 that Upstream x86_64 has. Due to people not wanting to have a different RPM spec file from upstream we will end up with an x86_64 package set too.. which as the good old Fat Controller would say "causes confusion and delay". So in order to satisfy various factions we are looking at add a COST to EPEL so that it would be higher than the default 1000 (say 1100).
What I would like to know is if this would affect CentOS-6, SciLin-6 or other repos so that we can deal with it now versus later. [And as much as I would like to go with repotags.. that has been seen as a non-starter.]
On 08/31/2010 09:52 PM, Stephen John Smoogen wrote:
With the differences between EL-6 architectures we are finding that we need to build things for PPC or i386 that Upstream x86_64 has.
This isnt really new to EL6, we ran into this issue with EL5 as well and have decided to publish all rpms into the main single distro repo( os + updates ).
Is there any reason why we should change that policy now ?
people not wanting to have a different RPM spec file from upstream we will end up with an x86_64 package set too.. which as the good old Fat Controller would say "causes confusion and delay". So in order to satisfy various factions we are looking at add a COST to EPEL so that it would be higher than the default 1000 (say 1100).
Cost itself wont solve the problem, there would need to be a blacklist at the repo end to make sure that rpms are never published that have a higher EVR than whats in the main distro. Even if the pkg does not exit for the same arch upstrem.
Ofcourse, the fact that epel will end up rebuilding packages that are in rhel core is going to be an interesting twist - specially when pkg maintainers are different.
What I would like to know is if this would affect CentOS-6, SciLin-6 or other repos so that we can deal with it now versus later. [And as
The only real issue would be when packages overlap, and what is the best way to address that is something that would need to be handled at the third party repo side of things ( so not Red Hat or CentOS ). We are already working towards having a public build queue that exposes a json interface, so automating stuff around that should not be hard for anyone.
much as I would like to go with repotags.. that has been seen as a non-starter.]
Is'nt epel the only repo not using a repo specific tag ?
- KB
On 9/1/10 5:57 AM, Karanbir Singh wrote:
Ofcourse, the fact that epel will end up rebuilding packages that are in rhel core is going to be an interesting twist - specially when pkg maintainers are different.
How can this possibly work with other 3rd party repos? Or does EPEL still not admit that other repos exist and are absolutely necessary?
On 09/01/2010 03:55 PM, Les Mikesell wrote:
On 9/1/10 5:57 AM, Karanbir Singh wrote:
Ofcourse, the fact that epel will end up rebuilding packages that are in rhel core is going to be an interesting twist - specially when pkg maintainers are different.
How can this possibly work with other 3rd party repos? Or does EPEL still not admit that other repos exist and are absolutely necessary?
The mere fact that Stephen asked here is the proof that EPEL DOES care about other repos. I also would like to point to Kevin's message ( https://www.redhat.com/archives/epel-devel-list/2010-August/msg00158.html ) which also proves that EPEL does try to avoid creating interoperability problems [*] Please, let's focus on technical issues and not restart an useless flame war.
[*] even if (sadly) other maintainers do not care about anything beyond fedora
On Wed, 1 Sep 2010, Manuel Wolfshant wrote:
The mere fact that Stephen asked here is the proof that EPEL DOES care about other repos. I also would like to point to Kevin's message ( https://www.redhat.com/archives/epel-devel-list/2010-August/msg00158.html ) which also proves that EPEL does try to avoid creating interoperability problems [*]
Please, let's focus on technical issues and not restart an useless flame war.
The elided [*] comment tosses some fuel toward the ignition source, no? One swallow does not a Spring, make
It is a fair question -- dist tags / repotags were kept out by the efforts of some with @redhat emails. Has that changed?
[I dont CARE they make the external file name fuglier, frankly -- if a packging entity will not sign their work with a brand that can be readily discerned by external inspection, I'm not much interested in them anyway]
There is a long tradition of differing level of interoperability. Sadly, although one might wish that any archive can interoperate with any archive, and that one never 'steps' on another archive, that can can never come to pass, for reasons noted in my post a couple years back to the EPEL ML
The obvious means of maximizing portibility and NOT stepping on another archive, is simply building packages that depend ONLY on LSB provided interfaces, and uses a private namespace, assigned by LANANA that approach exists, has existed, and still work today. It is merely cumbersome -- so automate it!!
The other parts of Smooge's question have as much to do with Red Hat's plans for interaction with its community adjunct archive, its Linux product in chief and the non-distribution of binary restrictions EPEL operates under, and the commercial partners adjunct archive. While I don't mind being asked, I certainly don't feel it is my, nor indeed CentOS', mandate to tell Red Hat how to run their business
I'll just point at LSB, and say: It is there for a reason
-- Russ herrold
On 9/1/2010 9:33 AM, R P Herrold wrote:
The mere fact that Stephen asked here is the proof that EPEL DOES care about other repos. I also would like to point to Kevin's message ( https://www.redhat.com/archives/epel-devel-list/2010-August/msg00158.html ) which also proves that EPEL does try to avoid creating interoperability problems [*]
Please, let's focus on technical issues and not restart an useless flame war.
The elided [*] comment tosses some fuel toward the ignition source, no? One swallow does not a Spring, make
It is a fair question -- dist tags / repotags were kept out by the efforts of some with @redhat emails. Has that changed?
It's not so much a flame as an observation that package managers don't and can't work with uncoordinated changes in the same namespace. And repotags don't do much to help unless the package manager uses them - although they do help in diagnosing problems after they've happened.
There is a long tradition of differing level of interoperability. Sadly, although one might wish that any archive can interoperate with any archive, and that one never 'steps' on another archive, that can can never come to pass, for reasons noted in my post a couple years back to the EPEL ML
I'm not convinced. I've got plenty of disk space. If you are going to modify a stock library, name it something else and name the package it's in something else - and make the things that need your non-stock changes use your copy instead. Do the same things you'd do with it if you were developing and testing a modified version on your own machine while keeping the stock version in place and running. This also allows the scenario where different users on the same machine want to run packages from different repos.
The obvious means of maximizing portibility and NOT stepping on another archive, is simply building packages that depend ONLY on LSB provided interfaces, and uses a private namespace, assigned by LANANA that approach exists, has existed, and still work today. It is merely cumbersome -- so automate it!!
I'm not convinced there either. Even if you follow LSB guidelines, uncoordinated packagers are going to step on each others' choices in compile options, config file layout.
I'll just point at LSB, and say: It is there for a reason
Does one or the other of the epel and rpmforge copies of viewvc violate lsb? If an update flips from one to the other your setup is broken - and it doesn't even involve dependencies.
On Sep 1, 2010, at 12:04 PM, Les Mikesell wrote:
It's not so much a flame as an observation that package managers don't and can't work with uncoordinated changes in the same namespace. And repotags don't do much to help unless the package manager uses them - although they do help in diagnosing problems after they've happened.
Well since "observations" have become folk lore, I am forced to respond here. If you wish detailed responses move to some other list where I can subscribe: Note that I am routinely "moderated" on the usual mailing lists.)
Summary comments below:
package managers don't and can't work with uncoordinated changes in the same namespace.
FALSE.
E.g. smart quite happily handles both *.deb and *.rpm (and 4 other formats) with zero coordination. Then there's PackageKit which also doesn't require package coordination.
Please note that I did NOT say RPM in andy of the above. There are some rather simple things that can be done in the rpmlib "engine room" to avoid the need for "coordination".
FALSE is the summary point.
The obvious means of maximizing portibility and NOT stepping on another archive, is simply building packages that depend ONLY on LSB provided interfaces, and uses a private namespace, assigned by LANANA that approach exists, has existed, and still work today. It is merely cumbersome -- so automate it!!
I'm not convinced there either. Even if you follow LSB guidelines, uncoordinated packagers are going to step on each others' choices in compile options, config file layout.
Again whether you are convinced (or not) is purely your opinion.
LSB and LANANANANANA were actually designed to address difficulties in linux distro coordination, not only with API/ABI issues, but also with package distribution.
The failure of LSB and LANANANANANA to make any progress says more about "coordianted" pointed ignorance from distro vendors than anything else.
73 de Jeff
On 9/1/2010 11:20 AM, Jeff Johnson wrote:
Summary comments below:
package managers don't and can't work with uncoordinated changes in the same namespace.
FALSE.
E.g. smart quite happily handles both *.deb and *.rpm (and 4 other formats) with zero coordination. Then there's PackageKit which also doesn't require package coordination.
Please note that I did NOT say RPM in andy of the above. There are some rather simple things that can be done in the rpmlib "engine room" to avoid the need for "coordination".
FALSE is the summary point.
How does it automatically handle the scenario where two different packagers build the same-named package at the same version rev in two different repos, and then they alternately advance the revs? My contention is that it is impossible to handle this correctly for all possibilities of what might be the correct thing to do. How does it handle the scenario where both supply the same-named library with different compile options and you have other packages that depend on both build types? What about the simple case where the packagers have just abstracted different things out of the upstream config files into settings under /etc/sysconfig for RH-style startup so they break if you flip versions?
<snip>
centos-devel ain't the place to attempt rational discussion. And I have no wish to interfere with smooge's RFC re EPEL.
73 de Jeff
On Wed, Sep 1, 2010 at 04:57, Karanbir Singh mail-lists@karan.org wrote:
On 08/31/2010 09:52 PM, Stephen John Smoogen wrote:
With the differences between EL-6 architectures we are finding that we need to build things for PPC or i386 that Upstream x86_64 has.
This isnt really new to EL6, we ran into this issue with EL5 as well and have decided to publish all rpms into the main single distro repo( os + updates ).
Is there any reason why we should change that policy now ?
Well this was more aimed at EPEL than CentOS. With us building stuff for PPC64 we end up building dependencies that mimic what is in TUV and thus CentOS.
people not wanting to have a different RPM spec file from upstream we will end up with an x86_64 package set too.. which as the good old Fat Controller would say "causes confusion and delay". So in order to satisfy various factions we are looking at add a COST to EPEL so that it would be higher than the default 1000 (say 1100).
Cost itself wont solve the problem, there would need to be a blacklist at the repo end to make sure that rpms are never published that have a higher EVR than whats in the main distro. Even if the pkg does not exit for the same arch upstrem.
Yes supposedly this can be done in our koji/bodhi now.
Ofcourse, the fact that epel will end up rebuilding packages that are in rhel core is going to be an interesting twist - specially when pkg maintainers are different.
Yes.. the rule will be that those packages will be built only from upstream sources with any trademarks 'ripped' out. Though I doubt any of the packages we are dealing with have upstream trademarks (perl-cpan-OMGitsfullofstars being the main culprit).
What I would like to know is if this would affect CentOS-6, SciLin-6 or other repos so that we can deal with it now versus later. [And as
The only real issue would be when packages overlap, and what is the best way to address that is something that would need to be handled at the third party repo side of things ( so not Red Hat or CentOS ). We are already working towards having a public build queue that exposes a json interface, so automating stuff around that should not be hard for anyone.
Ah cool.
much as I would like to go with repotags.. that has been seen as a non-starter.]
Is'nt epel the only repo not using a repo specific tag ?
That I know of, yes. I am outvoted on this one though.. from as many people outside of RH as inside.
-
Jeff Johnson -
Karanbir Singh -
Les Mikesell -
Manuel Wolfshant -
R P Herrold -
Stephen John Smoogen