FAQ
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.]

--
Stephen J Smoogen.
?The core skill of innovators is error recovery, not failure avoidance.?
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
? Herb Kelleher, founder Southwest Airlines

Search Discussions

  • Karanbir Singh at Sep 1, 2010 at 6:57 am

    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
  • Les Mikesell at Sep 1, 2010 at 8:55 am

    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?

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Manuel Wolfshant at Sep 1, 2010 at 9:34 am

    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
  • R P Herrold at Sep 1, 2010 at 10:33 am

    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
  • Les Mikesell at Sep 1, 2010 at 12:04 pm

    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.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Jeff Johnson at Sep 1, 2010 at 12:20 pm

    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
  • Les Mikesell at Sep 1, 2010 at 12:40 pm

    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?

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Jeff Johnson at Sep 1, 2010 at 12:44 pm
    <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
  • Stephen John Smoogen at Sep 1, 2010 at 5:26 pm

    On Wed, Sep 1, 2010 at 04:57, Karanbir Singh 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.




    --
    Stephen J Smoogen.
    ?The core skill of innovators is error recovery, not failure avoidance.?
    Randy Nelson, President of Pixar University.
    "We have a strategic plan. It's called doing things.""
    ? Herb Kelleher, founder Southwest Airlines

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos-devel @
categoriescentos
postedAug 31, '10 at 4:52p
activeSep 1, '10 at 5:26p
posts10
users6
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase