Re: Why is yum not liked by some? -- CVS analogy (and why you're not getting it)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Fri, 2005-09-09 at 12:05, Mike McCarty wrote:

> Les, what you seem to want is to put a tag on the files so one
> can create a snapshot version. A simple date will not do what you
> want. I know that you think it will. But I did configuration management
> for years, and you just do not have any concept of how difficult
> the problem is. You need to think of yum as being a transport agent,
> because that's really all it is. Yes, it knows about some dependencies,
> but it can't know about everything there is to know.

Please explain what would go wrong if yum simply ignored the
presence of files newer than a specified date.   

> I'm here to tell you that I did software development and participated
> in configuration management at a large corporation, and we had *teams*
> of over 100 engineers and testers working to do what you want, and
> we *still* had some holes in the process.

I'm not asking to deal with arbitrary revisions to same-named
files here.  I'm asking for repeatable actions with all the
same stuff available plus possibly some new things I'd prefer
to ignore.  Everything still exists in the repository and
would be available if you extracted the version numbers from
the machine with the prior run with rpm -q and fed it explicitly
to yum to install.  If there is a reason that yum would not
make exactly the same decision again by itself if it just
could be told to ignore the subsequently-added files in the
repository I am missing something.

> You need to think of yum as just being a fancy version of wget. You
> can ask wget to get a whole web page and its pieces, and it will.
> And it'll even resolve some dependencies to fix up the hyperlinks
> between the files to fit the structure it builds on your machine.
> But that's it. It's a transport mechanism. So is yum. It's a transport.

The only new thing I'm asking is for it to pretend some new files
weren't there.

> >>All I want is to be able to pretend that additions more recent than
> >>a prior run weren't there.
> 
> No, that is not what you want. What you expressly requested was to
> be able to recreate a yum install, and that the results be consistent.

Then I'm missing why yum would make different decisions than it
did when the files actually weren't there.

> That requires co-operation all along the whole software development
> chain, starting with source, and having a dedicated QA team to create
> the certified packages. It requires a certified source library of
> all the pieces, and a method for the development tools (compilers,
> assemblers, linkers, etc.) to pass along information about what version
> went into the build, and the test team to be able to certify
> what versions were tested together during integration.
> 
> This is inconsistent with "open software development on the web".
> 
> It requires a management structure.

That's all there, and all been done.  That's the beauty of the
current system and the value of using yum in the first place.
And that's why I've pressed this conversation this far.  Everything
in the repository has already been version-numbered, dependency
checked and well tested.  It's insane to think that I can do
a better job of this than has already been done.  The only
extra step is that I need to check for any surprises in interaction
with home-grown apps and scripts (and in a distribution like
Centos this would most likely mean the app was broken if it ever
happened).

> > Until you run your _own_ YUM repository and use createrepo a few times,
> > you will be oblivious to what a YUM repository is.
> 
> I believe you have struck the nail upon the head with perfect
> orthogonality.
> 
> In fact, he seems to have no concept of what configuration management
> is.

The configuration management is already done.  All I'm asking for is
a way to access what was done last week (which is still there) and
ignore available additions.  Yes it can be done with a complete
snapshot of every repository state that I might want to repeat
an update from.  It could also be done by making a snapshot of
a current repository and physically removing the files I don't
want yet.  It could also be done if the yum program just ignored
the files I don't want yet.  The last option just seems nicer.

--
  Les Mikesell
    lesmikesell@xxxxxxxxx



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux