FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 03-24-2011, 07:18 PM
Karanbir Singh
 
Default Why not a fusion between CentOS and SL?

On 03/24/2011 05:52 PM, James Antill wrote:
> Right. Personally, given that you aren't shipping the exact binaries
> that upstream ship, I would say that all CentOS builds should start with
> a .1 added to the end of release, and then increment that for any
> rebuilds you need to do. I'd also have the packages provide the upstream
> NEVR, as well.

We do that already, but it depends on what state its in and why there
was a bump and if the package has made it to user machines. We never
rebuild or push a package that will need to be considered with buildtime
etc.

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 03-24-2011, 07:20 PM
Karanbir Singh
 
Default Why not a fusion between CentOS and SL?

On 03/24/2011 08:14 PM, James Antill wrote:
> Upstream: foo-1.2.4-8.el7
> CentOS: foo-1.2.4-8.el7_0.0c1
> CentOS: foo-1.2.4-8.el7_0.0c2

This would make a lot of people, very angry

Specially the crazy vendors who use pkg names and payload content
matching to workout what platform they are running on and conditionals
that result from it

we do change tag's for packages we need to change, or force a user side
bump on;

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 03-24-2011, 07:23 PM
Lamar Owen
 
Default Why not a fusion between CentOS and SL?

On Thursday, March 24, 2011 04:13:25 pm Karanbir Singh wrote:
> yum reinstall; does this quite well - also we dont want anything like
> that for centos QA. We dont test how pkgs change in place, the aim is to
> test how user side stuff changes through upgrades.

If I may ask a CentOS QA process question, then, is what is the QA on making sure that the package that gets pushed to -testing and then to -updates is the latest build of a particular EVR tuple? Just curious, since buildtime seems a reasonable thing to use for that sort of thing. Or, for that matter, that the QA feedback is for the correct build of a particular EVR for a package?

Like I said, just curious, because I did run into that issue, which is why I always bumped release on RPMs I pushed out even for the most trivial rebuild reason; I got burned by it once; but if the question is inappropriate, my apologies.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 03-24-2011, 07:29 PM
Jeff Johnson
 
Default Why not a fusion between CentOS and SL?

On Mar 24, 2011, at 4:13 PM, Lamar Owen wrote:

> On Thursday, March 24, 2011 02:40:59 pm Jeff Johnson wrote:
>> But priority in the "real world" of multiple repositories is too arbitrary
>> and not based on intrinsic details like dependency closure and difficult
>> to administer reliably:
>> Who *exactly* chooses the priority? What criteria are the basis?
>
> Well, Jeff, it partially goes all the way back to a subject related to a discussion you and I had years ago, in Red Hat 6.1/6.2 timeframes, of why PostgreSQL database data upgrades couldn't be done in %pre, %install, %post, or %postun scriptlets. We had been talking about the anaconda chroot and some of the deficiencies of that chroot and how the environment wasn't stable enough to do the ambitious things I wanted to do, and you made a statement along the lines that all RPM knows is packages; it doesn't know squat about distributions, just packages.
>

Well my comments way back when were based on real world experience
attempting to automate postgresql database format conversions. That was
actually attempted in RPM scriptlets (RHL5.2? I fergit) and turned out to be rather
a disaster with ENOSPC failure conditions.

(aside)
These days sqlite3 is embedded @rpm5.org, so its quite possible
to do a full dump/reload operation now that "disk space is cheap".

But the salient point is that RPM is a pretty stoopid program, implements
mechanism but not policy, and largely does whatever its told to do.

That's merely a restatement of "... doesn't know squat about distributions ..."

> Substitute repositories for distributions, and you have today's situation. RPM itself doesn't care where a package gets its dependencies from, just that they're satisfied.
>

Depends on POV. The operant POV is
rpm == dpkg
which is no more accurate than
rpm == apt
RPM is a weird mixture between apt (and depsolvers) and dpkg (and archiver
operations).

(aside)
RPM @rpm5.org is tracking not only the *.rpm file digest, but also the origin/stat(2)
of the original *.rpm file, and ghas many other features that aren't "doesn't care".

But you are likely quoting a statement from me that
If two packages have the same Provides:, either will do.
That's merely a statement of logic: the Requires: assertion will have
an identical truth table no matter which package is chosen.

But "preference" and installer "policy" isn't well implemented anywhere
that I see. Sure there's "repositories" and "applications" and "distros",
but there isn't any implementation of "preference".

Go ask for Suggests: to be implemented in RPM and listen carefully to the
random replies. Everyone wants "preference", but there's no meaningful
(afaics) implementation around. It *is* a non-trivial problem to solve.

> I'm going to have to look up that e-mail, because I know I kept it....and I'm fairly certain it was you, but it might have been someone else, might have even been Nottingham.
>

"Patience grasshoppers" still cracks me up (but I have a warped sense of humor)

>> And freshrpms was wonderful and Matthias is truly a gentleman, his involvement
>> is missed.
>
> Yes, it is.
>
>> But everyone moves on to other interests than Linux eventually.
>
> Indeed. If it weren't my 'daily driver' OS I might not still be around these parts.

And if it wasn't for an RPM fork (which pissed me off: I have no intent of "losing")
I'd likely have moved on to something else too.

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

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 03-24-2011, 07:44 PM
Karanbir Singh
 
Default Why not a fusion between CentOS and SL?

On 03/24/2011 08:23 PM, Lamar Owen wrote:
> If I may ask a CentOS QA process question, then, is what is the QA on making sure that the package that gets pushed to -testing and then to -updates is the latest build of a particular EVR tuple? Just curious, since buildtime seems a reasonable thing to use for that sort of thing. Or, for that matter, that the QA feedback is for the correct build of a particular EVR for a package?

There are three things here that are important :

1) the QA team guys are very wired up to this process - and are very
aware of the fact that packages will change with no EVR change; they are
also aware of the fact that the testing that were doing is from <whats
out there now> => <what we want to put out there > ( as opposed to <what
we tested yesterday> => < what we want to test today> )

2) We only ever sign packages once they are accepted; and only signed
packages are pushed publicly

3) Every package build ( so srpm -> binary rpm conversion ) runs with a
uniq build-tag; the buildtag has no relation to package name-E:VR.arch
or anything like that. Its a purely generated ID. So its still possible
to go back and get stats, logs etc for every build that we did.
irrespective of what we did ( eg: there are lots of things that were
exclusive arch: s390 )

None of that probably answers your question. So here is how the 'move to
repo happens'. By hand or the system is smart enough to replace all
binary rpms with newer builds if the srpm metadata is the same. So you
can ever only have one <name>.<arch> in the os/repo as output from one
srpm; and their buildid needs to match ( which will handle corner cases
like a subpackage going away etc ); for updates/<arch>/repo there can
only be one name-E:VR.arch from one source rpm; and since the test is
only run when a new set of binaries are output, the latest will always
win[1]

- KB

[1]: this is not always true or the desired result, and needs manual
intervention.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 03-24-2011, 08:02 PM
Lamar Owen
 
Default Why not a fusion between CentOS and SL?

On Thursday, March 24, 2011 04:44:43 pm Karanbir Singh wrote:
> 1) the QA team guys are very wired up to this process
[snip]
> 2) We only ever sign packages once they are accepted; and only signed
> packages are pushed publicly
[snip]
> None of that probably answers your question.

No, these two items do answer what I really wanted to know very nicely, at least to my satisfaction, thanks much for taking the time to answer. In a nutshell, the QA people only ever work with unsigned packages, you keep them tagged with unique tag ID's, and when it's signed it's Golden.

While this thread has taken a few sweeping off-topic turns (not a small number of which I'm sure I'm at least partially responsible for), I've learned yet a little more about these processes, and I hope others have as well.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 03-25-2011, 08:02 PM
David Hollis
 
Default Why not a fusion between CentOS and SL?

On 03/24/2011 01:52 PM, James Antill wrote:
> Right. Personally, given that you aren't shipping the exact binaries
> that upstream ship, I would say that all CentOS builds should start with
> a .1 added to the end of release, and then increment that for any
> rebuilds you need to do. I'd also have the packages provide the upstream
> NEVR, as well.
> To me that would still satisfy the "don't unnecessarily alter
> specfiles" mission and all of the "we changed FOO.bin but can't reflect
> that in FOO.src" problems go away.

This policy would be murder for end users that have to maintain
compliance with various requirements such as SOX404, PCI, etc.

If you really wanted to modify the release number, while likely
maintaining ABI compatibility, you would in many ways be a new distro
based on upstream sources.

As much as it adds a bunch of fun for the CentOS devs rebuilding the
same package differently to get it to match upstreams binary while
maintaining the same NVR, it's just the nature of the beast.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-10-2011, 11:25 AM
Johnny Hughes
 
Default Why not a fusion between CentOS and SL?

On 03/23/2011 07:07 AM, Karanbir Singh wrote:
> On 03/23/2011 09:13 AM, carlopmart wrote:
>> Hi all,
>>
>> Please, first of all, I don't want to start a flame about this
>> subject. I only wnat to know CentOS's developers point of view about
>> this particular.
>
> we looked at this in the past and :
>
> - SL and CentOS have different goals, and neither of us are keen on
> adapting the other's
> - its good to have two projects, its keep user options open
>
> thats about it.
>
> - KB

I would also like to make sure that no one on this list thinks that we
have anything but the utmost respect for the Scientific Linux project.
The devels over there are very nice and we have worked with them in the
past and I am sure will continue to do so in the future.

Connie and Troy are very knowledgeable and they produce a quality
product. If I was not using CentOS, I would certainly be using
Scientific Linux.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 04-10-2011, 11:57 AM
Johnny Hughes
 
Default Why not a fusion between CentOS and SL?

On 03/23/2011 06:24 AM, carlopmart wrote:
> On 03/23/2011 12:11 PM, Kenni Lund wrote:
>> 2011/3/23 carlopmart<carlopmart@gmail.com>:
>>> On 03/23/2011 11:48 AM, John R. Dennison wrote:
>>>> On Wed, Mar 23, 2011 at 11:43:53AM +0100, carlopmart wrote:
>>>>>
>>>>> Both statements says the same with different words ... SL says
>>>>> "compatible" too, like CentOS ...
>>>>
>>>> Honestly... This is a development list. If you need to have the
>>>> concept of binary compatibility explained to you then I fear you
>>>> are in the wrong place.
>>>>
>>>>
>>>
>>> Honestly ... I know the meaning of the concept of "binary compatible". I
>>> don't understand is where you see the difference between CentOS and SL
>>> about this. Where is the difference?
>>
>> carlopmart, please go to the -users list with this, one of the CentOS
>> devs actually posted a relevant example of the SL/CentOS differences
>> earlier today:
>> http://lists.centos.org/pipermail/centos/2011-March/108389.html
>>
>> Best regards
>> Kenni
>
> I don't doubt about Johnny Hughes says in his email, but there is an
> important point is not to taken into account: SL5.6 is not released and
> Johnny makes his comparision between SL and CentOS 5.6.
>
> ok, then the principal two reasons to don't fusion CentOS and SL are:
>
> a) SL is not "binary compatible"
>
> b) SL binaries are linked in different manner than TUV does.
>
> ?? am I right??
>
>

I never said that SL does anything wrong. And yes, they have not
"released" 5.6 yet, so it might be fixed then.

If people want CentOS, they should use CentOS. If they want Scientific
Linux, they should use Scientific Linux.

I was only pointing out that one can find fault with any distribution.

I do not know what exact process is for SL ... I do know what it is for
CentOS.

For the record, neither CentOS nor SL is 100% compatible with the
upstream product. Ned Slider pointed out that some of our Kernel
modules are build against some different than upstream because they
built on a version of the kernel that they did not release. We do not
have access to that kernel source code, so we built against a released
kernel.

The real issue is that the upstream product is not necessarily self
hosting and they sometimes build against stuff that is not released.
That is just how it is. Then again, they never said their goal was to
produce a self hosting distribution. They also do not need to provide
every iteration of their software that resides on the build system, and
they do provide more information than any other enterprise vendor.

There is no reason to slam SL to build up CentOS (or vice versa) ...
both CentOS and SL are quality free enterprise distributions. Each can
be used for enterprise level server or workstation uses.

I can say that if I was not using CentOS then I would be using SL.

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

Thread Tools




All times are GMT. The time now is 07:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org