[WBEL-devel] Respin 1 Status

[John Morris]

Ok, haven't been very active on the list lately, been squashing nits. The
i386 respin is pretty much ready for wider distribution. Just rolled a
new set of iso images that SHOULD pass muster, if I can't find anymore
defects on this set I'll post them tomorrow as a release candidate by
bitrorrent only for a couple of days and see if I end up wearing a brown
paper bag again.

x86_64 is another story, adding in the errata keeps blowing chunks along
the way as I rebuild, install packages to satisfy deps and build some
more. Been trying various orderings but so far it always ends up with a
collapsing system, segfaulting at will, rpm not working anymore, etc.
About to just give up on starting at Respin 1 and build a clean 3.0 then
go back and see if I can find all of the intervening packages and
build/install them one at a time and see where it is breaking. Grr.

Also been rethinking the whole up2date thing again and unless I'm having a
brain cramp I don't think I need to worry about hatching a new one or
forcing a new sources file. The people I want to get are the ones who
DIDN'T edit the file so being unchanged rpm should replace it for them and
drop an .rpmnew for all you guys on this list. btw, the new sources file
is going to have entries for Dag, ATrpms and JPackage ready to uncomment
and use.

[Axel Thimm]

--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi John,

BTW a John Morris <***@butchwax.com> discussing about kernel module
rpms on ATrpms-devel is not you, or is it? :)

Post by John Morris
Also been rethinking the whole up2date thing again and unless I'm having a
brain cramp I don't think I need to worry about hatching a new one or
forcing a new sources file. The people I want to get are the ones who
DIDN'T edit the file so being unchanged rpm should replace it for them and
drop an .rpmnew for all you guys on this list. btw, the new sources file
is going to have entries for Dag, ATrpms and JPackage ready to uncomment
and use.

ATrpms has no WBEL support yes (but is scheduled to come very soon). I
just painfully set up some x86_64 FC2 support (quite a lot of packages
with hardcoded /lib/ out there ...).

I don't know how intrusive you want to be with WBEL vs RHEL
differences, but I would suggest to split off the config files out of
up2date/yum/apt etc., so that you can upgrade the config files
separately, and even allow site admins to craft their own config file
rpms to deploy locally.

That's how ATrpms deals with the config files for apt and yum (not yet
up2date, there is too little demand for up2date on consumer line RH
series). It allows flexible modification to the list of repos.
--=20
Axel.Thimm at ATrpms.net

--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAxY4vQBVS1GOamfERArshAJ0UjAnlQXX0R3dJ6FCnV2RrKNIzDACgj+96
F/VLZVdo4I+9zd+SXZAjFqs=
=eFoX
-----END PGP SIGNATURE-----

--zhXaljGHf11kAtnf--

[William Hooper]

I don't know how intrusive you want to be with WBEL vs RHEL differences,
but I would suggest to split off the config files out of up2date/yum/apt
etc., so that you can upgrade the config files separately, and even allow
site admins to craft their own config file rpms to deploy locally.

Why? The config files will not be changed if they have been edited.

That's how ATrpms deals with the config files for apt and yum...

And judging by the mailing list threads is a constant source of irritation...

[Axel Thimm]

--7pXD3OQNRL3RjWCz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Post by William Hooper

I don't know how intrusive you want to be with WBEL vs RHEL differences,
but I would suggest to split off the config files out of up2date/yum/apt
etc., so that you can upgrade the config files separately, and even all=

ow

Post by William Hooper

site admins to craft their own config file rpms to deploy locally.

=20
Why? The config files will not be changed if they have been edited.

No, that's not the issue. It is for being able to update the config
files with more flexibility. As a site admin it will be easier for me
to rebuild whitebox-package-config containing (only) the config files
for the resolvers than to rebuild up2date/apt/yum etc. binaries as
well.

Post by William Hooper

That's how ATrpms deals with the config files for apt and yum...

=20
And judging by the mailing list threads is a constant source of irritation...

Not really, it is simply something that is being muttered about, for
the sake of creating FUD. It obviously works ;)

Similar things have happened to named/bind where you have
configuration in different replacable packages. Finer granularity
increases modularity, flexibility and reusability.

Anyway that was just a thought. I don't know how often the config
files would change in WB's context. For ATrpms (including more than a
dozen different repos in the configs) they change several times a
week, so splitting off the config files was a must, especially in
times before the debuginfo package splits, where apt for instance was
several MBs large.
--=20
Axel.Thimm at ATrpms.net

--7pXD3OQNRL3RjWCz
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAxbo8QBVS1GOamfERAmbeAJ4h6HIidEbYia4fUQ2BENGk1A4JUQCfWg21
HE7DmrzwrbrXRTgXLBnfpSI=
=tP9l
-----END PGP SIGNATURE-----

--7pXD3OQNRL3RjWCz--