Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   CentOS Development (http://www.linux-archive.org/centos-development/)
-   -   Looking for input from EPEL (http://www.linux-archive.org/centos-development/421403-looking-input-epel.html)

Jeff Johnson 09-01-2010 04:20 PM

Looking for input from EPEL
 
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


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Les Mikesell 09-01-2010 04:40 PM

Looking for input from EPEL
 
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@gmail.com


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Jeff Johnson 09-01-2010 04:44 PM

Looking for input from EPEL
 
<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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Stephen John Smoogen 09-01-2010 09:26 PM

Looking for input from EPEL
 
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.




--
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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel


All times are GMT. The time now is 06:55 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.