On Thu, Mar 24, 2011 at 2:12 AM, Manuel Wolfshant
<wolfy@nobugconsulting.ro> wrote:
> On 03/24/2011 11:07 AM, Dag Wieers wrote:

>>>>> if you examine certain packages you will notice that there are linking
>>>>> differences between what SL ships and what RH ships.
>>>> Can you give an example of such package/binary?
>>> I can but I am not sure that I may. So I won't.
>> Manuel,
>>
>> I don't see any reason why you may not share incompatibilities found in
>> Scientific Linux ? Can you shed a light on why that is ?
>>
>> Other team members already disclosed two of those, so is there a reason
>> why not all of them are shared with the Scientific Linux team ?
> There was no deep secret, just a matter of timming. It was not my answer
> to give, I wanted to be sure that Johny & Karanbir take the needed
> fixing steps first.

I just wanted to make a quick note that you/we are referring to the
*Alpha* version of SL 5.6. At that stage of the game, chances are that
they have not gone through all the testing. There are good reasons why
it is Alpha. I'm not saying the "incompatibility" issue will
definitely disappear in their Beta but this is just an observation
most people seem to be overlooking.

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

On 3/24/11 7:33 AM, Akemi Yagi wrote:
> On Thu, Mar 24, 2011 at 2:12 AM, Manuel Wolfshant
>
>>> Other team members already disclosed two of those, so is there a reason
>>> why not all of them are shared with the Scientific Linux team ?
>> There was no deep secret, just a matter of timming. It was not my answer
>> to give, I wanted to be sure that Johny& Karanbir take the needed
>> fixing steps first.
>
> I just wanted to make a quick note that you/we are referring to the
> *Alpha* version of SL 5.6. At that stage of the game, chances are that
> they have not gone through all the testing. There are good reasons why
> it is Alpha. I'm not saying the "incompatibility" issue will
> definitely disappear in their Beta but this is just an observation
> most people seem to be overlooking.

Also note that you can't just 'yum update' from those SL alpha versions to the
final release, so even if CentOS did ship alpha/beta versions it wouldn't make
life that much easier. On the other hand it would be nice if yum knew enough to
do that - or to understand different repositories and be able to always update
from the same source or be told when to switch and reinstall.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

> Also note that you can't just 'yum update' from those SL alpha versions to the
> final release, so even if CentOS did ship alpha/beta versions it wouldn't make
> life that much easier. On the other hand it would be nice if yum knew enough to
> do that - or to understand different repositories and be able to always update
> from the same source or be told when to switch and reinstall.
the new yum ( in fedora ) knows that, basically it prefers to install
from the same repo from where you already have stuff.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Thu, 24 Mar 2011, Les Mikesell wrote:

> Also note that you can't just 'yum update' from those SL alpha versions to the
> final release, so even if CentOS did ship alpha/beta versions it wouldn't make
> life that much easier. On the other hand it would be nice if yum knew enough to
> do that - or to understand different repositories and be able to always update
> from the same source or be told when to switch and reinstall.

Yes, I have contemplated writing two Yum plugins for such cases:

- to only consider to update packages from the same repository/source or
in case dependency resolution requires a different course of action, to
ask the user (no more exclude/include nonsense)

- to always update to same/newer updates based on build-time, this would
be absolutely useful for CentOS QA testing where packages are being
rebuild with the exact same version/release and in those cases you want
to get the latest build.

If anyone is interested, don't wait for me to implement it as free time is
pretty scarce around here :-/

--
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Thu, 24 Mar 2011, Manuel Wolfshant wrote:

>> Also note that you can't just 'yum update' from those SL alpha versions to the
>> final release, so even if CentOS did ship alpha/beta versions it wouldn't make
>> life that much easier. On the other hand it would be nice if yum knew enough to
>> do that - or to understand different repositories and be able to always update
>> from the same source or be told when to switch and reinstall.
>
> the new yum ( in fedora ) knows that, basically it prefers to install
> from the same repo from where you already have stuff.

Great ! This helps with cross-repository use in Yum.

--
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Thursday, March 24, 2011 08:51:30 am Les Mikesell wrote:
> Also note that you can't just 'yum update' from those SL alpha versions to the
> final release, so even if CentOS did ship alpha/beta versions it wouldn't make
> life that much easier.

The problem with updates from a rolling alpha/beta to the GA release is that it is possible that the package contents change but the epoch:version-release tuple doesn't; especially given a rebuild of the upstream source package (which cannot have its EVR changed and maintain strict compatibility) due to things like the libtalloc versioning situation previously mentioned.

I haven't checked to see if it's implemented in EL6, but this sounds like a situation tailor-made for yum distro-sync. I'm not sure, however, how distro-sync acts when packages are actually different but their EVR stays the same.

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

On 3/24/2011 8:42 AM, Dag Wieers wrote:
> On Thu, 24 Mar 2011, Manuel Wolfshant wrote:
>
>>> Also note that you can't just 'yum update' from those SL alpha versions to the
>>> final release, so even if CentOS did ship alpha/beta versions it wouldn't make
>>> life that much easier. On the other hand it would be nice if yum knew enough to
>>> do that - or to understand different repositories and be able to always update
>>> from the same source or be told when to switch and reinstall.
>>
>> the new yum ( in fedora ) knows that, basically it prefers to install
>> from the same repo from where you already have stuff.
>
> Great ! This helps with cross-repository use in Yum.

I never quite understood why that wasn't designed in from the start. It
always had the assumption that all repositories were coordinated (or
forced the end user to know more than was usually possible to know about
them), when from the beginning the base repositories involved had
policies that guaranteed that uncoordinated 3rd party repositories would
always be a necessity. The new rpmforge layout helps somewhat, but I've
pretty much had to keep all 3rd party repos disabled and explicitly
enable them with the command line switch just to install/update single
packages.

And while I'm ranting about yum, there has to be a way to pick a
repository mirror that doesn't load your caching proxy with a copy of
every file from every mirror. Since at least Centos 5 the mirrors are
insanely fast so it really doesn't matter any more, but it still doesn't
make much sense to make the mirrors do the extra work.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Thursday, March 24, 2011 10:40:37 am Les Mikesell wrote:
> On 3/24/2011 8:42 AM, Dag Wieers wrote:
> > On Thu, 24 Mar 2011, Manuel Wolfshant wrote:
> >> the new yum ( in fedora ) knows that, basically it prefers to install
> >> from the same repo from where you already have stuff.

> > Great ! This helps with cross-repository use in Yum.

> I never quite understood why that wasn't designed in from the start.

Because the yellowdog updater-modified developers didn't have that lofty of a goal in mind from the start?

Hindsight is 20/20; perhaps people thought at the time that cooperation in a Debianic way could happen between the various 3rd party repos and make repo mixing problems a thing of the past? We know now that that didn't happen, almost entirely due to personality/political things. Not casting any blame at all; but the people who saw the 'unified Debianic repository' dream die, in real-time (you were around then, Les, being just as much of a gadfly then as now) know what happened. That's about the time I dropped all my fedora list subscriptions; I've just since F13 resubscribed to the fedora-users list.

And there was a bigger issue to address, that of dependency solving. I'm glad the yellowdog updater-modified developers chose to solve that problem first, and not worry about overdesigning for a problem that had not yet reared its ugly head (at the time). Oh, and let's not forget the absolutely wonderful presto and delta rpm work.

Or we could all still be on apt-rpm and still be having multilib and related issues. And while synaptic is still far and away the best package management GUI out there bar none, the apt-rpm backend has (or at least had) significant issues at that time.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

on 3/23/2011 3:00 AM Ljubomir Ljubojevic spake the following:
> carlopmart wrote:
>> On 03/23/2011 10:27 AM, Ljubomir Ljubojevic wrote:
>>> Scientific Linux uses upstream source to create their own repo, without
>>> desire to be 100% compatible.
>>>
>>> CentOS project is dedicated to provide (as close as possible) 100%
>>> compatibility. It's not just a rebuild of upstream sources, goal is tu
>>> *duplicate* RHEL.
>>>
>>> It's that simple. And this was answer many times in this and other
>>> mailing lists, forum threads....
>>>
>>> Ljubomir
>>>
>>
>> I know that SL includes some custom components like OpenAFS in their
>> distribution, but base system is the same as CentOS. Then, I repeat, why
>> not?
>>
>
> Then, I repeat, because SL *does not care* to build 100% *binary*
> compatible packages, fo r CentOS it's a must.
>
> Look at it this way. Upstream is a Coca-Cola Co. SL is Pepsi. They use
> publicly available formulas from upstream in order to create product
> that is as good as upstreams, but is not *the 100% same* since their
> production formulas are not ***100%/absolutely*** the same.
>
> In this analogy, CentOS is the industrial espionage guy who constantly
> steals new formulas from upstream in order to create **exact/100%**
> replicas of upstream product. For better analogy, lets say that
> acquiring that formula is illegal.
>
> So, how do you propose that Pepsi and counterfeit work together.
>
> P.S. "counterfeit" is extremely wrong to say for CentOS, but analogy
> demands clear distinction of persons involved, so I beg all to forgive
> me for this.
>
> Ljubomir
It would be more like, CentOS uses freely available list of ingredients, but
without the secret recipe. So they work and work until the end product is as
close as humanly possible. SL takes those ingredients and when they get "close
enough" they say "done!"

I say if anyone thinks SL is better... Don't let the virtual door hit you in
the nethers on your way out... If you want CentOS... Just be patient. Getting
4.9 and 5.6 working first was a good and valid decision, as a new deployment
of a new and untested distro is usually lower on the priority list anyway. The
unpaid and overworked staff is working as fast as they can...

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

On Thu, 24 Mar 2011, Lamar Owen wrote:

> Or we could all still be on apt-rpm and still be having multilib and
> related issues. And while synaptic is still far and away the best
> package management GUI out there bar none, the apt-rpm backend has (or
> at least had) significant issues at that time.

Hey ! There was nothing wrong with apt-rpm, I've been using it until
November last year on CentOS-5 before I switched to RHEL6. The multi-lib
problems were exagerated and fixed, the biggest problem was the lack of
development after the main developer moved to Conectiva, and the second
maintainer to Red Hat.

But I do prefer python over C++ anytime, though speedwise it was
unbeatable.

--
-- dag wieers, dag@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel