Re: another approach to what current does

Basically, what John said, but:

On Tue, 2002-08-13 at 11:03, Alex Kramarov wrote:
> 
> ----- Original Message -----
> From: "John Berninger" <[email protected]>
> To: <[email protected]>
> Sent: Tuesday, August 13, 2002 3:15 PM
> Subject: Re: [Current-server] another approach to what current does
> 
> 
> >         First, and foremost to my mind, it has absolutely no way to
> > distinguish between architectures.  The client doesn't always determine
> > which architecture of a given package is pulled - the server will
> > sometimes override the client, or say "no, use this one - it's better".
> 
> haven't seen this happen when debugging the client server communications. As
> far as i could see, the client was always requesting the correct
> architecture package. Also i couldn't see any additional communication
> between the client and server except the auth phase, downloading the package
> list, and getting the headers. i believe the client makes it's decisions
> based on the package list, and i simply pass to it the package list i get
> from the RHN server.

Older versions of the protocol worked as John is remembering. 2.7 and
later work as Alex is saying.

> 
> >         Second, it's unable to resolve dependencies, which is one of the
> > bigger parts of what RHN/up2date buys you over running Slackware (again,
> > IMHO).  That's actually the largest part of the server code, is
> > remembering all the dependency information and solving it properly when
> > a client connects and asks for updates.
> 
> WHAT ??? up2date resolves dependencies fine, basing on the package list and
> the downloaded headers.

The client, on its own, can solve _some_ dependancies fine.
About 90% of the time, thats how things work.

You simply haven't got a test case that calls 
up2date.solveDependancies() yet.

0.8.0 or something had everything BUT solveDependancies, and they worked
fine most of the time.



> 
> >         Third, it's unable to learn the concept of channels, which is
> > kinda critical to any future development of a server for up2date -
> > up2date without the ability to do channels is kinda like Red Hat Linux
> > without the ability to do RPM - it's not.
> 
> I don't agree that channels are so crutial to up2date, at least to the needs
> I am trying to answer. I am trying to provide a simple solution for a
> homogenous envirnment - a couple of computers have the same RedHat version
> installed. I am not trying to provide a single server that will provide
> updates for 7.0, 7.1, 7.2 and 7.3 machines at the same time, although it is
> possible with my architecture. I have ajusted (i don't know if you have seen
> version 0.02 of nrh) the server to return to the client the base channel of
> the client's distribution (for example if the client is 7.2, the server will
> seek content of redhat-linus-7.2 in /var/spool/up2date) , before that the
> server was hardcoded to redhat 7.3

Depending on the needs of the client site, either of you could be right.

> 
> >         I agree, it's certainly not a waste of time, because we (or I,
> > more specifically) have already stolen some ideas from nrh (I just have
> > to actually make them work in code, now), but given that Current 1.3
> > uses Apache to achieve the same level of scalability connection-wise and
> > that it's about the same amount of work (from what I've read so far) to
> > set up either a Current 1.3.x server or an NRH server, I'm dubious as to
> > how long NRH will survive in the wild.
> 
> My intention is not to run a separate project, if the same functionality can
> be achieved by another project, as long as it fits my requirements : simple,
> no db, no additional, complex installations to the server, simple updates

I'm willing to be proved wrong, but up2date without a db = yum.
If I wanted up2date like functionality without a db, I'd run yum.

> consistent with the RHN content. Remember, i was developing this under the
> impression that there is no GPL up2date server project - i couldn't find
> "current" at the time. We are not here to make money, so if we can get the
> best of the 2 projects under your roof, fine, i can even contribute to the
> development and merging effort. For example, i will be happy to see a fake
> rhn-register server done in the same way as nrh, meaning that it will return
> a valid output to a freshly installed client , enough to generate a system
> id that nrh auth server will accept. The id can be completely fake
> (hardcoded to the server and distributed to unlimited number of clients). I
> never installed current, but i am under the impression that it has a complex
> rpm management system, that has to be updated manually when you want to add
> new packages (correct me if i am wrong) ? i on the other hand, simply need
> do download RHN content for a base channel of the redhat version i am using,
> and pass it on to the clients.

Again, current/RHN - db = yum here. You're going to run into trouble
with the solvedeps calls.

> 
> On the other hand, if current will not be able to meet these goals even
> after taking some ideas from NRH (sorry for repeating : simple, no db, no
> additional, complex installations to the server, simple updates consistent
> with the RHN content ), i do believe that this project will find it's target
> population, and will survive in the wild.

Try yum.

> 
> It all depends on the out cooperation. Waiting for your response.
> 
> Alex.
> 
> _______________________________________________
> Current-server mailing list
> [email protected]
> http://lists.dulug.duke.edu/mailman/listinfo/current-server
> 
> 
-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.