[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20041113032305.GA2024@openwall.com>
Date: Sat, 13 Nov 2004 06:23:05 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: Owl-current moved to glibc 2.3.x
On Sun, Nov 07, 2004 at 07:14:32PM +0100, Maciek Pasternacki wrote:
> On Boomtime, The Aftermath 20, 3170 YOLD, Solar Designer wrote:
>
> > I'm really surprised you went through all that trouble. What you
> > were supposed to do is a simple "make installworld" over your older
> > system. That would have taken care of all the issues you mention
> > automagically.
>
> Oh. I've always seen Owl's build system as a build system and make
> installworld as, well, installer. After reading the scripts I see
> it's more useful than I thought. I didn't find it fully documented
> after eyeball-grep (and grep -i for upgrade and installorder) on
> native/Owl/doc/
Yes, we're lacking on documentation. We'll probably need to write an
"Owl User's Guide" that one could read as a book. But I've been
postponing that for after we get an intuitive installer.
> (for me installorder.conf is especially important
> because I don't use postfix and trying to install it could mess up my
> qmail installation; am I right thinking adding third-party srpm
> compiled with `make PACKAGE=' to installorder.conf will make `make
> installworld' take care of installing/upgrading it?).
Yes. But the most important bit for you is to comment out "postfix"
from installorder.conf.
> >> One is not bumping up the release on all recompiled packages
> >
> > Yes, we're indeed well aware of it and, while definitely not elegant,
> > this is intentional. There's simply no obviously-correct way to
> > decide when a package's release number should be bumped. If we would
> > spend the time to determine whenever a library a package depends on
> > has been changed (or would develop a set of scripts to track that) and
> > would bump release numbers each time this happens, that would result
> > in a lot of mostly unnecessary changes to spec files.
>
> On the other hand, installworld simply reinstalls files for all
> packages; if release numbers were bumped each time, it'd create
> seemingly unnecessary changes to spec files but it'd make it possible
> to upgrade only packages that really need to be upgraded.
True.
Perhaps there's also the option to enhance rpm such that it would
(optionally?) see if buildhost has changed or buildtime has increased
and consider a package newer if any of these is true.
> > OK, the glibc change is a significant one. And so is OpenSSL. But
> > what about all the smaller changes, such as re-building with new gcc?
> > For C++ code, this is a significant change too (dependencies on
> > libstdc++ change), but for plain C?.. Should we go ahead and bump
> > release numbers in almost(?) all spec files each time we update gcc?
>
> Well, when binary compatibility is broken I think release version
> should go up. When package contents significantly change
> (recompilation with newer gcc IMHO isn't a significant change unless
> previous gcc version had bugs -- gcc upgrade to next major version is
> maybe something that maybe should be represented by release number
> change, but minor number change IMHO can go without notice).
Not for C++ code, -- there, it often breaks binary compatibility.
But I got your point.
> > Oh, so you aren't fully upgraded yet? It should have taken just a few
> > minutes with "make installworld", really. :-)
>
> Well, Owl upgrade didn't take so long (but, to be honest, it included
> running an ad-hoc one-liner equivalent of installworld), but there are
> also third-party packages that need to be upgraded and rebuilt
> (Python, Jabberd, Jabber transports, Apache, MySQL, PHP (including
> upgrade from php4 to 5), Perl CPAN modules, some minor packages like
> stunnel or qmail-tlsd and libraries it all depends on... argh). ;)
You're right. It all depends on how much third-party software you had
installed on top of Owl.
> Also I'm not sure whether it's a bug or a feature but
> %_unpackaged_files_terminate_build is set to 1 in /usr/lib/rpm/macros;
Yes, this is intentional. And we went to the trouble to make sure we
deal with all files explicitly.
We should probably adjust the "rpminit" script to set it the other way
around for building third-party packages.
> in PLD unpackaged files just spit out warnings and as far as
> I remember it was the case in pre-upgrade Owl.
No, rpm-3.0.6 which we used previously simply didn't have the feature.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
