New up2date with local dir access
by Mike Chambers
When setting up to check updates for a local dir, it seems that when the
checks get to the obsoletes menu, it stays there. I have to hit the X
on that menu, go back once, use another up2date entry to let it check
then it finishes showing package headers and such from the local dir.
This is all on a dir that mirrors everything in the i386 rawhide dir.
Everything seems to work except when you select to check for updates on
the rawhide dir, and it gets to the obsoletes part.
[mike@bart mike]$ rpm -q up2date up2date-gnome
up2date-3.9.12-2
up2date-gnome-3.9.12-2
This is the local dir check line..
### an local directory full of packages
### format
dir Rawhide /home/nfs/download/linux/redhat/rawhide/
Any ideas?
--
Mike Chambers
Madisonville, KY
"To be or not to be, is the dumbest question I ever heard!"
20 years, 9 months
The new up2date ?
by Mark Guzzo
Hi all,
I set up the new UP2DATE and it works great, but I have a question.
How do I set it so that I'm no asked this question for EVERY package I
want to install (from RAWHIDE)?
"The package Foo-Bar-x.x is not signed with a GPG signature. Continue?"
Mark
20 years, 9 months
Wine and MS Office
by Paul Sery
Has anyone gotten Wine to work with MS Office? The MS installer chokes
under Severn. I've tried Wine versions from 8/03 back to 6/03.
20 years, 9 months
Re: Minimal Install Option
by Jef Spaleta
Bill Rugolsky Jr. wrote:
>Beyond that, agreement tends to dissolve, because intended uses vary
>widely.
That was sort of my point...about having a consensus view not being
ignored. Good luck finding that consensus. Maybe a 460Meg "minimal"
doesn't work for everyone...but if it works for 80% of the userbase or
for the intended audience or for an intended use...then maybe that
460Meg minimal install is the best fit for the development resources on
hand...and we need to move on.
And there is a logic fault involved with any argument that says you can
assuredly create any sort of install process meeting the competing
interests of easy maintainability from the development side, easy of
use/simplification for the non-technical audience...and easy of
use/customization for the technically proficient user. I humbly submit
there are trade-offs invovled and there is no perfect solution. And in
the final analysis...the technically savvy users have tools already to
do customized installs...kickstart just makes more sense for a lot of
situations where technically proficient users want the option of being
lazy, instead of pipedreaming about an installer that meets their
specific usage interests. And if kickstart doesn't do it for you and you
are in the 0.1% of people who know they need a very exactly specific
install where you can't go back in with a post install script and
uninstall things you don't need because you have exactly 200Megs of
harddrive space you can use for the install...well rolling your own isos
is probably best...anaconda-runtime also exists for a reason. There is
an intended audience for rhl....and i would again humbly suggest that
putting in a lot of easy to find options in the default iso images meant
for the 0.1% of the userbase outside of the intended audience who should
be using kickstart or anaconda-runtime to make extremely customized
installs...is going to lead to problems with the intended userbase and
waste developer time which could be spent streamlining the installer and
debugging the installer for the intended install situations. The people
who KNOW they need to squeeze a Red Hat install into 100 Megs of
harddrive space, are going to need to know far more about other avenues
of streamlining and customization to get things to work just like they
want them to. 30Megs just for the default kernel modules
alone....yippie!!!!!...at some point you build a customized iso to get
exactly what you want.
The way forward for everybody, is to work out how to create a 2 stage
install that moves a lot of the package selection crap out of
anaconda...and into a firstboot situation...a firstboot situation where
you get access to the actually system resources...and not those
resources available in the installer ramdisk image. So what if
anaconda's "minimal install" includes a set of packages that you end up
not wanting to install. Harddrive space is CHEAP. We need to find one
and only one distro provided "balanced" minimal install sequence that
provides enough tools so that you can come back in after a firstboot and
do a wealth of customization..including package removal...via
repositories...via a well baked r-c-packages..via personalized
scripts..etc....outside of the limited ramdisk anaconda gets access to.
If being able to remove packages post 1st stage install is the sticking
point...that needs to be worked on. Clean package removal is important
in a number of situations...even for the intended non technically savant
audience. Figure out how to do that cleanly...and you help
everyone...not just the 0.1% of people who need to do a 73Meg harddrive
firewall install. Once we recognize the package removal is a hard
problem...that doesn't mean we should work around that problem with
craptastic kludges that complicated the installer process. We need to
tackle the hard problem of how to do package removals well...and
streamline the 1st stage installer....that is a better use of the
limited developer time....its the biggest long term bang for the
buck/doughnut/beer/pizza/long winded patriotic essays/whatever you use
to bribe developers with to do yer bidding.
If you need to worry about having only 200Megs of Harddrive space or
only 4 megs of memory at this point in the game...you really should be
rolling yer own media sets or something other than expecting the default
rhl image to cater to systems limitations for which predate
cobol....anaconda-runtime exists for a reason.
>Separating packages into executables and libraries
>is a good idea not only because it allows multiple libfoo* installs, but also
>because it saves space when all that one wants are the libs, and not
>the default front-end application, which may have additional dependencies.
Saves space....i would say that at this point for the "intended"
audience for rhl...saving space is not a priority. Diskspace is cheap.
But I'm sensing a very technical and very drawn out debate about what
the pro's and con's to very fined grained packaging is. And the only
people really qualified to wade into this one...are people who should be
busy fixing high priority bugreports...instead of posting to this thread
or sending email to me or you offlist. But I imagine taking a good hard
look at what it would mean to allow multiple libfoo* installs would be
another very enlightening discussion of the trade-offs among the
interests of difference segments of the userbase..
-jef"if only rpm-analyzer worked not only with hdlists but with
installed rpmdb's...gui reverse dependancy trees are neat"spaleta
20 years, 9 months
Re: Minimal Install Option
by Jef Spaleta
Bill Anderson wrote:
>Right now, I am working ona python script that explores a given group
>and determines a package list for the entire group. With this, my goal
>is (initially) to be able to have it take the Mandatory, and later
>Default, options in the group, list them, and then follow it's group
>requirements and do the same up the tree (all the way to Core).
is rpm-analyzer the project you seek?
http://www.maisondubonheur.com/rpm-analyzer/
if yer going through this much trouble for a python script maybe you can
hack the extra mandatory/default/optional functionality into
rpm-analyzer proggie while yer at it.
-jef
20 years, 9 months
Is it possible to have more feedback
by Tom Malone
I realise that RedHat is doing all it can to make this project a
success, and I was wondering if it possible to have a really simple web
page that gives out when RedHat hope to get the next beta out or when
they hope the infrastructure is in place with a bug banner saying these
are not set in stone.
20 years, 9 months
Re: Minimal Install Option
by Jef Spaleta
Bill Anderson wrote:
> Sorry, yes I've been going on the beta. In the beta, it is a group
> defined in the comps.xml file.
Now I maybe totally blind...but in the comps.xml on my beta disk1 iso, a
simple grep for Minimal/minimal doesn't snag its own group. What I get
is the Base group with a description of:
<description>These packages include a minimal set of packages. Useful
for creating small router/firewall boxes, for example.</description>
It is true that minimal is not a "type" of install like workstation or
desktop...to get a minimal install in the beta you have to select
custom, and then then in the group selector there is a choice of minimal
or everything...after the specific group choices. But I'm not sure if
minimal is really its own group in the comps.xml file...the finished
alternative comps.xml file will be interesting to test.
-jef
20 years, 9 months
new up2date for testing
by Adrian Likins
I'll be putting new up2dates up at:
http://people.redhat.com/~alikins/up2date/severn/
As often as I can. These are for testing purposes
only and unofficial.
add:
yum up2date-test-repo-severn-i386 http://people.redhat.com/alikins/up2date/severn/RPMS/
to /etc/sysconfig/rhn/up2date to get to these with up2date.
(note some versions of up2date out there might try to automatically
update to these versions if you add that, if you dont want that,
you can either set updateUp2date=0 in /etc/sysconfig/rhn/up2date)
or just grab the new packages which only auto update up2date if
it's from an rhn channel).
And for added fun, you can try testing rollbacks. They
work perfectly. A shining example of modern software engineering
in its finest form. Unbreakable. Fair and Balanaced. A
testament to perfection of form and function. Flawless
in it's beauty, and overwhelming in its precision.
A flawless beauty
unbreakable purity
cherry blossoms fall
To enable, check "Enable Rollbacks" on the
Retreivel/installation screen of the gui in
`up2date --config` or set "enabledRollbacks"
to 1 if text config is more your style.
And if thats not enough excitement, try
uncommenting the one line in /etc/rpm/macros.up2date
This enables "all erase" transactions. Aka, rollbacks
on package installs, not just package upgrades, for yall
rollback newbies.
This will create rollback rpms on every up2date
package install/upgrade (remove too, for that matter).
You can then rollback the last rollback with:
up2date --undo
To reinstall the previous version of that package
(including any modified config files).
If anything breaks... yeah, right, like this could possibly
break. I already said it was perfect. Anyway, if anything
breaks, my good friend bugzilla wants to here about it.
Since you won't be needing it, I'll go ahead and provide
a pointer url to <a href="http://makeashorterlink.com/?J12662B95">
the right place to file a bug</a>. But you want need that.
Adrian
20 years, 9 months
firstboot and --reconfig
by Féliciano Matias
/etc/rc.d/init.d/firstboot :
case "$1" in
start)
if grep -i reconfig /proc/cmdline >/dev/null || [ -f /etc/reconfigSys ]; then
echo -n $"Running system reconfiguration tool"
/usr/sbin/firstboot --reconfig
rm -f /etc/reconfigSys
exit 0
fi
Is there a use for reconfig ?
Keep in mind that firstboot create /etc/sysconfig/firstboot that prevent
further execution.
A new bug report related to firstboot :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102067
--
Féliciano Matias <feliciano.matias(a)free.fr>
20 years, 9 months