On Thu, 24 Mar 2011, Jeff Sheltren wrote:

> On Thu, Mar 24, 2011 at 9:50 AM, Les Mikesell <lesmikesell@gmail.com> wrote:
>> On 3/24/2011 10:44 AM, Jeff Johnson wrote:
>>>>> 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?
>>>>
>>
>> I think it was the opposite - that they had the lofty goal of having all
>> repositories coordinated even though that is clearly impossible unless
>> you can dictate a jailed iphone-like world.
>
> There weren't really "external" repositories when yum came out. I
> won't speak for Seth, but in my opinion, the goal of yum was "help end
> RPM dep hell". And thankfully it did (combined with lots of packaging
> improvements in rh/fedora, etc.).

Well, you had plenty, RPMforge, FreshRPMS, ATrpms, NewRPMS, PlanetCCMA,
and many many more. That was before something like Fedora Extras existed.

--
-- 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 3/24/2011 11:54 AM, Jeff Sheltren wrote:
> On Thu, Mar 24, 2011 at 9:50 AM, Les Mikesell<lesmikesell@gmail.com> wrote:
>> On 3/24/2011 10:44 AM, Jeff Johnson wrote:
>>>>> 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?
>>>>
>>
>> I think it was the opposite - that they had the lofty goal of having all
>> repositories coordinated even though that is clearly impossible unless
>> you can dictate a jailed iphone-like world.
>
> There weren't really "external" repositories when yum came out. I
> won't speak for Seth, but in my opinion, the goal of yum was "help end
> RPM dep hell". And thankfully it did (combined with lots of packaging
> improvements in rh/fedora, etc.).

Really? I thought freshrpms was around (and wonderful) back when you
had to use some apt derivative to use it.

--
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 11:58:03 am James Antill wrote:
> This is kind of a unique situation, in that it's pretty well accepted
> that if you are rebuilding for any reason you need to change at least
> the release in some way.

The problem, at least for CentOS, becomes the stated policy of no changes to the upstream source RPM unless absolutely necessary. Changing the release is a change to the upstream source RPM, and doesn't qualify as absolutely necessary.

> I kind of understand why you don't want to, but I'm not sure it's worth
> the problem of having M versions of a particular NEVRA. Does this happen
> anytime after initial distro. creation?

It would happen any time a source RPM would have to be rebuilt due to binary linkage differences; the initial build(s) that had the wrong linkage version(s) and the final, binary compatible confirmed build would have the same EVR but different contents and different dependencies. As long as a 'cannot change the source RPM' policy is to be followed this will be true. This is true specifically for the problem RPM with the wrong libtalloc dependency that has been mentioned, for update 6 of C5 (I really, really, really strongly dislike the use of a minor version to reflect the upstream's quarterly large updates).

> As above, we currently mostly only look at NEVRA for identifying
> packages in any part of yum.
> For rpmdbv's we also look at the checksum, so I had thought about doing
> something so you could more easily "reinstall" anything with changed
> checksums:
[snip code segment]
> Probably the most significant downside is that you can't sort based on
> that, you can only tell that X is different from Y not which is
> preferred but then I'd _really_ want to discourage people publishing
> multiple NEVRAs that are identical ... and one assumes that when you are
> doing your builds you rarely (if ever?) want to go backwards.

Methinks that is the strongest argument against a CentOS alpha or beta being published, since by definition there are going to be exactly that: two or more packages with identical NEVRA tuples with different contents and different checksums. I say by definition since it is one of the stated goals of CentOS to not change the upstream source package in any way unless a trademark issue or in the case of kernel signing where it's necessary. If you can't change the source RPM you can't change NEVRA. Unless you want to tag every single RPM in the distribution with a distribution tag.....or a repository tag....

Please read Connie Sieh's first paragraph, and Troy's immediately previous paragraph, in a December 17, 2010 posting to scientific-linux-devel, found in their archives at:
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1012&L=scientific-linux-devel&T=0&I=-3&P=2967

And while I could easily quote that here, I think reading the whole e-mail, including the quoted lines from Troy, will be beneficial.

> In theory we could also use "buildtime", but I'm very wary of making
> that into a minor release id as it would encourage the multiple NEVRAs
> problem and it is much less linear in other distributions (although
> they'd tend to respect NEVRA .

Well, other distributions have control of their own source RPM's NEVRA; rebuilding from source RPM by default reliquishes control of NEVRA to upstream. So if you don't get the build right on the first go, you are going to have more than one package with the same NEVRA, and either buildtime or checksum will show the difference; buildtime is more desireable, I would think. If the distribution is being built out of an SCM or full buildsystem like koji, and the upstream is not already built into a NEVRA-frozen source RPM, then you don't have this problem. This is only a problem when you're rebuilding from somebody else's source RPMs.

Or when you're maintaining an upstream RPM set and find out that you didn't update before churning out that last build..... you get a quandary of having to bump release because you forgot to issue yum update before building. With mock, of course, that problem goes away, but I maintained RPMs before mock (or mach) existed, and I tried to always bump release for every single build, regardless. Of course, then you have to put in a changelog line and explain the rebuild.... and many times it was just tempting to not bump release and just throw the rebuild up there, slipstreaming it into the ftp site....

> Also worth noting is that the one NEVRA dup. with different checksums I
> can see on F13 is libjingle in updates and fedora-chromium ... and those
> have the same buildtime (I assume spot just resigned it).

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

On Thursday, March 24, 2011 12:50:47 pm Les Mikesell wrote:
> I think it was the opposite - that they had the lofty goal of having all
> repositories coordinated even though that is clearly impossible unless
> you can dictate a jailed iphone-like world.

I used my own adjective 'Debianic' to indicate that Debian has for the most part already done this with no 'jail' required. It can be done, and it can be done with a fully open structure, if all the players will just do it. Of course, instead of third party repos you get whole different distributions, like Ubuntu, as a result, but that's preferrable to multiple overlapping and in many areas mutually exclusive repositories. The situation right now is not as bad as I have seen it, and that is good.

Repository unification is the better goal; making the various repos work together when they aren't coordinated is much more difficult, and is the very definition of the word 'kludge.' It didn't happen; and won't happen: but it would really have been nice had it happened.

There are going to be situations where your mix isn't going to work at all, ever, because the packages you want need conflicting versions of various components; there is no technical solution for this other than not mixing and putting the two mutually exclusive 'things' on two different boxes, real or virtual.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Thursday, March 24, 2011 01:01:11 pm Dag Wieers wrote:
> Well, you had plenty, RPMforge, FreshRPMS, ATrpms, NewRPMS, PlanetCCMA,
> and many many more. That was before something like Fedora Extras existed.

It was even before Fedora the distribution existed; you of course had the fedora.us repository.....

But I distinctly remember using a mix of the above with Red Hat Linux 9, and prior, using apt-rpm (and by hand before apt-rpm existed), before Seth tackled the problem yum solved really well.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Thu, 2011-03-24 at 13:19 -0400, Lamar Owen wrote:
> On Thursday, March 24, 2011 11:58:03 am James Antill wrote:
> > This is kind of a unique situation, in that it's pretty well accepted
> > that if you are rebuilding for any reason you need to change at least
> > the release in some way.
>
> The problem, at least for CentOS, becomes the stated policy of no
> changes to the upstream source RPM unless absolutely necessary.
> Changing the release is a change to the upstream source RPM, and
> doesn't qualify as absolutely necessary.

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.

Of course this technically is changing the .spec ... and there _could_
be problems with 3rd party rpms requires/conflicts/obsoletes, but it
seems like a much cleaner solution.
Obviously changing this before CentOS-7 would be complete insanity, but
I think it's worth considering for then.

> > I kind of understand why you don't want to, but I'm not sure it's worth
> > the problem of having M versions of a particular NEVRA. Does this happen
> > anytime after initial distro. creation?
>
> It would happen any time a source RPM would have to be rebuilt due to
> binary linkage differences; the initial build(s) that had the wrong
> linkage version(s) and the final, binary compatible confirmed build
> would have the same EVR but different contents and different
> dependencies. As long as a 'cannot change the source RPM' policy is
> to be followed this will be true. This is true specifically for the
> problem RPM with the wrong libtalloc dependency that has been
> mentioned, for update 6 of C5 (I really, really, really strongly
> dislike the use of a minor version to reflect the upstream's quarterly
> large updates).

Right, sorry, I worded my question badly. What I meant to ask is:

I understand that you probably rebuild the same NEVRAs "a lot" during
the initial distro. creation, as you are guessing about what the build
environment of each SRPM was.
I also understand that this happens "sometimes" for updates, Eg.
libtalloc or util-linux, but ... how often is this a problem for
updates? Is it 1-2 packages a year, 1-2 a month, more?

> > As above, we currently mostly only look at NEVRA for identifying
> > packages in any part of yum.
> > For rpmdbv's we also look at the checksum, so I had thought about doing
> > something so you could more easily "reinstall" anything with changed
> > checksums:
> [snip code segment]
> > Probably the most significant downside is that you can't sort based on
> > that, you can only tell that X is different from Y not which is
> > preferred but then I'd _really_ want to discourage people publishing
> > multiple NEVRAs that are identical ... and one assumes that when you are
> > doing your builds you rarely (if ever?) want to go backwards.
>
> Methinks that is the strongest argument against a CentOS alpha or beta
> being published, since by definition there are going to be exactly
> that: two or more packages with identical NEVRA tuples with different
> contents and different checksums.

Personally I doubt a beta would be useful anyway. As I don't think
people want a CentOS beta released quickly ... they "just" want a CentOS
release released quickly, and if you release a beta (esp. with the same
NEVRAs as release) they'll either ignore it or treat it as a release.

> Unless you want to tag every single RPM in the distribution with a
> distribution tag.....or a repository tag....
>
> Please read Connie Sieh's first paragraph, and Troy's immediately
> previous paragraph, in a December 17, 2010 posting to
> scientific-linux-devel, found in their archives at:
> http://listserv.fnal.gov/scripts/wa.exe?A2=ind1012&L=scientific-linux-devel&T=0&I=-3&P=2967

Yeh, this is the above "we change FOO.bin, but don't want to change
FOO.src" problem. I understand, but I'm still tempted to say "don't do
that then".

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

On Thursday, March 24, 2011 12:06:31 pm seth vidal wrote:
> Have you looked at yumex in f14 or rawhide? Or from Tim's builds here:
> http://repos.fedorapeople.org/repos/timlau/yumex/
>
> I ask b/c he's made a lot of great changes to yumex and it is faster.
>
> worth looking at.

I will do that; while yumex is no synaptic, feature-wise, it beats kpackagekit hands down, IMO. Thanks for the pointers, and thanks for yum.

And I have noticed the speed improvements in yum over the years; I still have a CentOS 3 box running in production, and comparing yum of that day (2.0.8) with today's yum is....well, no comparison, really.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 3/24/2011 11:57 AM, James Antill wrote:
>
> The known "plans" atm. are more of the "make the priorities plugin suck
> less" variety, than to add vendor/buildtime/repoid/etc. directly into
> update calculations.

Yes, but given more than 2 choices, priorities are likely transient
things over an enterprise release's lifetime and even if your favorite
2nd choice changes you aren't going to want its likely incompatible
versions to clobber the ones you've already installed. I think you'd
see that now if you flip between epel/rpmforge's viewvc. The code may
even be the same but the config files are different enough to break things.

The other thing I've always thought should be included in yum is an
option to ignore packages in a repository newer than a specified
timestamp. That would let you update one machine, test everything, then
update some other set of machines to the tested state even if new
packages have been introduced to the repositories between the times in
question. That might not cover every possible change, but it would be
better than nothing or having to build snapshot copies of entire
repositories to avoid new items.

--
Les Mikesell
lesmikesell@gmail.com

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

On 3/24/2011 12:45 PM, Lamar Owen wrote:
>
>> I think it was the opposite - that they had the lofty goal of having all
>> repositories coordinated even though that is clearly impossible unless
>> you can dictate a jailed iphone-like world.
>
> I used my own adjective 'Debianic' to indicate that Debian has for the most part already done this with no 'jail' required. It can be done, and it can be done with a fully open structure, if all the players will just do it. Of course, instead of third party repos you get whole different distributions, like Ubuntu, as a result, but that's preferrable to multiple overlapping and in many areas mutually exclusive repositories.

But it can't be done starting with Red Hat's policy, which was/is the
real world starting point.

> Repository unification is the better goal; making the various repos work together when they aren't coordinated is much more difficult, and is the very definition of the word 'kludge.' It didn't happen; and won't happen: but it would really have been nice had it happened.

An even better goal would be an LSB standard that actually lets 3rd
party binaries work. Period, no qualifications except maybe minimum
kernel and glibc versions. Let me know when any distro cares.

> There are going to be situations where your mix isn't going to work at all, ever, because the packages you want need conflicting versions of various components; there is no technical solution for this other than not mixing and putting the two mutually exclusive 'things' on two different boxes, real or virtual.

Yes, and this tends to become a big problem as enterprise distributions
age well beyond the 'best used by' date of a lot of components and more
than one 3rd party wants to update a base library. But it could be
improved if you could keep those from jumping around as the different
repos bump numbers at random times.

--
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 01:48:17 pm Lamar Owen wrote:
> It was even before Fedora the distribution existed; you of course had the fedora.us repository.....

After sending this out I realized I should have said 'there of course was the fedora.us repository' because that was Warren's thing, not yours. Dastardly colloquial usage of the second person personal pronoun as a generic address to a set of people but easily misinterpreted as singular when plural was meant.... where's thou when you need him?
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel