[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mzxtr0fr.fsf@lizard.king>
Date: Sun, 07 Nov 2004 19:14:32 +0100
From: Maciek Pasternacki <maciekp@...hy.fnord.org>
To: owl-users@...ts.openwall.com
Subject: Re: Owl-current moved to glibc 2.3.x
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/ (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?). I'd love to see
the build system and scripts described in more detail.
>> 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.
Now I usually just upgrade with poldek and it upgrades only packages
which version or release numbers have changed. Since important
changes (like secfixes) get their release numbers bumped it usually
works good enough and I don't need to re-create every file from every
package on each upgrade.
> 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). For me,
changes in package's contents or binary compatibility is when release
version should be increased -- dynamic linking will work well for
minor library changes (most of pre-upgrade Owl packages would run on
new glibc).
On PLD Linux Distribution, which I use for my desktop, packages'
release number change is used to indicate that package should be
rebuilt (because, e.g., some library has changed). In PLD the
distribution isn't recompiled as whole (as it is in Owl) but
individual packages are sent to `builder' machine. When after
building library binary package dependencies are broken, packages
that break them have their release version increased and are sent to
builder (actually, AFAIK, builder tracks CVS commits and when
package's version or release is upgraded it rebuilds the package
automatically -- it isn't confirmed in distro's docs though and
I don't have access to builders so I'm not 100% sure). Broken
dependencies in binary packages are detected with poldek.
> Basically, currently it is assumed that by far the most Owl users will
> use "make installworld". And if you do install packages manually,
> you need to realize that a matching package version number between
> Owl-current revisions or between different branches does not imply the
> package is built/linked against all the same library versions.
ACK. I wasn't aware of this; release number policy isn't documented
anywhere and it's certainly not what I expected. Relying on release
numbers have always worked well enough for me. I don't like the idea
of replacing all files in the system on each minor secfix but I'll
make sure now to run `make installworld' from time to time to make
sure everything's up to date.
>> Currently
>> poldek doesn't compile OOTB on Owl because of some autotools magic not
>> detecting librpm correctly;
>
> Is that still the case with the latest Owl-current?
Yes. In fact, it's the case only with the latest Owl-current (librpm3
was detected correctly and ran well). As soon as I'll have some
meaningful results as to where the problem is I'll post more info.
>> as soon as I'll get my system completely
>> up and running I'll track this down with poldek developers.
>
> 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). ;)
>> Second inconsistency is /usr/lib/rpm/macros -- default cpu is now
>> i686; since I run i586 system, I was surprised by rpmbuild creating
>> i686 binaries for me (even more surprised by it running
>> i686-pc-linux-gnu compiler and saving resulting binaries as .i386.rpm
>> files). Are binaries in -current also compiled for i686-pc-linux-gnu?
>> Why such change? Or maybe I don't understand some details about
>> compiling for different flavours of x86?
>
> Now, this may be a bug, and I wasn't aware of it. I'll let Galaxy
> investigate and fix it. He's the boss at our rpm package presently.
OK. Please let me know when something will be known about this (I'd
prefer not to change default RPM macros as much as I can).
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;
in PLD unpackaged files just spit out warnings and as far as
I remember it was the case in pre-upgrade Owl. If it's a feature I'll
just redefine it in my .rpmmacros (to allow third-party packages with
unpackaged files, like Python not packaging X11-related files without
X11 development packages in build-time, to build correctly) and live
with it.
>> (or, at least, rpm %pre script could be more informative,
>> maybe even print exact shell commands to convert the database without
>> doing too much harm to the system).
>
> Perhaps it should be made Owl-aware: detect that rpm is not running
> from within "make installworld" and explain that it probably should be.
Yes, it'd certainly be a good idea -- Owl binary RPMs are Owl-specific
anyway so it certainly won't break anything and adventurous users can
choose to rebuild RPM database by hand on their own risk (as I did). ;)
Thanks for reply,
--japhy
--
__ Maciek Pasternacki <maciekp@...hy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...For I was born with a habit, from a sign,
,|{-}|}| }\/ the habit of a windswept thumb,
\/ |____/ and a sign of the rain... } ( Fish ) -><-
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.
