[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEUL: Migration, and a brief recap
Paul Anderson wrote:
> On Thu, 8 Jan 1998, Kai Wetzel wrote:
> > > 2) We'll be using RedHat's package manager.
> > I agree. IMHO we should stay open for a switch in a later version IF:
> > debian is easy enough by then AND it's not going to drain too much power
> > from the SEUL team.
> No, no, no, you don't understand the way this works.
Hmm, please read what I wrote: "AND it's not going to drain
too much power from the SEUL team." This is a precondition
which must be met. You think it cannot be met, while I bope
it will be met eventually. Only time will show.
This doesn't change the idea that SEUL shouldn't tie
itself to anything for "all times". Things can change.
Of course it also doesn't change that SEUL should go
with rpm now and will probably stick to it for quite
some time because (among others):
- RedHat installation is more end-user oriented, so we'll
have way less work to do.
- There are people who know how rpm works so we can start
> There's no such thing as changing package managers,
Come on, even a commercial distribution switched package
managers (_to_ rpm), and they surely didn't have time to waste.
Again, I don't see this happen to SEUL anytime soon, certainly
not this year ;O)
> all we can do is start over from the
> beginning and throw out what we've done.
> All we can do is a total rewrite.
Your're exaggerating :°)
> The installer calls rpmlib functions internally, trying to gut
> these would be next to impossible.
Again, it's not a primary goal to switch package managers.
It's not impossible either. And there are likely to be much
more painful things in the work on SEUL then package managers,
no matter what manager is used (IMHO).
(Especially if we want to be really end-user ready)
It is also a good idea to write code in an easy to
read, well-structured fashion, no matter what
language, library, toolkit (etc.) is used.
I've looked at some KDE sources some time ago, and
the differences in maintainability are significant, even
though they all use Qt at the bottom.
> We start with RPM, we stay with it.
> No changing. Remember, guys, this is a ONE WAY trip.
Come on, I'm no lunatic, either =°) But it doesn't
have to be a one way trip :)
> And, as things
> stand RIGHT NOW, RPM is the better candidate. TTYL!
I'm inclined to agree on this one :O)