Unresolved dependencies in Rawhide 05/25/04
by Demond
Unresolvable chain of dependencies:
abiword 2.0.6-1 requires libcrlayeng.so.1
abiword 2.0.6-1 requires libcroco.so.1
abiword 2.0.6-1 requires libcrseleng.so.2
gnome-bluetooth 0.4.1-7 requires libcrlayeng.so.1
gnome-bluetooth 0.4.1-7 requires libcroco.so.1
gnome-bluetooth 0.4.1-7 requires libcrseleng.so.2
initscripts-7.54-1 requires pppd < 2.3.9
rusers-server 0.17-37 requires libproc.so.3.2.0
rusers-server 0.17-37 requires
libproc.so.3.2.0(_3_1_14)
19 years, 11 months
Installing without a CDROM or USB drive
by Tyler Larson
Unfortunately, the size of Fedora's boot image is too large
to fit on a floppy. If you're like me and don't have a CD burner
handy, but also can't boot off a USB drive, you can still boot the
install image from your hard drive.
As trivial as the process is, it took me a while to figure out that
it was an option. I'll explain it here to save others headache of
coming up with a way to install without having to burn any CDs.
Luckily you're already running FC1, right? And you already have
grub installed, right? Perfect. Just tell grub to boot the kernel
provided for USB drives (using the appropriate ramdisk image) and
you're done.
Here's a simple command sequence. Note that this isn't for the
novice. If anything below doesn't look familiar, don't do it.
cd iso_dir
mkdir mnt1 mnt2
mount -o loop FC2-i386-disc1.iso mnt1
mnt -o loop mnt1/images/diskboot.img mnt2
mkdir /boot/fc2inst
cp mnt2/vmlinuz mnt2/initrd.img /boot/fc2inst
umount mnt2
umount mnt1
rmdir mnt1 mnt2
reboot
When GRUB comes up, hit 'c' to bring up a command prompt...
GRUB> kernel /fc2inst/vmlinuz ramdisk_size=8192
GRUB> initrd /fc2inst/initrd.img
GRUB> boot
If you did it right, it should boot and run anaconda.
You can specify additional kernel parameters if you want to,
like the location of your kickstart file.
Obviously your file paths may vary (for example, depending on
whether you use a boot partition or not), but this should give
you an idea of the basic process. Adapt it to your own situation.
19 years, 11 months
anaconda CVS repository moved to rhlinux.redhat.com
by Jeremy Katz
This is a heads-up that the CVS repository for anaconda has moved from
its previous home of an internal server to the externally accessible
rhlinux.redhat.com. You can check it out by doing
cvs -d:pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS login
cvs -d:pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS co anaconda
This will give you the current trunk of anaconda development (ie, what's
destined for FC3 and beyond). I'm going to send a mail shortly with a
list of some of the things that myself and some of the other people at
Red Hat who work on anaconda are looking at or working on with the goal
of getting as much of it done as possible for Fedora Core 3 for
discussion or for others to pick up some of the ideas and run with them.
Cheers,
Jeremy
19 years, 11 months
Re: Making Fedora Core CD #1 Standalone -- Now you're seeing it my way!
by Bryan Smith
[ I think at this point I've spewed enough vapor, so it's time for me to
go off and do something. I really appreciate *EVERYONE'S*! input on
this. I'm going to try to have a "nailed down" comps.xml by the
weekend, and identify some of the "BS dependencies" that should be
removed (if any) on various, basic packages. ]
Chris Chabot wrote:
> This is indeed a big can of worms. To further complicate the matter,
> you always need to keep the upgrade path in mind to. If someone is
> running redhat 8,9, fedora core 1 or 2, they should be able to
> download the install cd's and upgrade their existing system.
I think some people are missing the fact that I _do_ recognize that.
And that's why I'm advocating that the full "Core" _not_ be touched.
This new sub-Core would be explicit. Ideally it would be Core CD #1.
> This means a whole lot of packages _have_ to be included to provide
> compat-XYZ or newer versions of the already installed packages. This
> kind of means that 90% of the existing packages are automaticly tied
> in on the install cd's.
Right. I don't disagree with that.
> So with that in mind, what profit can still be gained by re-ordering
> packages around on cd's, and making minimal install cd's?
> IMHO you could make the first cd a "Basic but relatively complete"
> install cd, which includes all basic apps, web browsers, basic
> services and server apps, yum, system-config-packages, etc; Which you
> could use to install a new functional and working Workstation, or
> Server installation.
I think that was what I was saying.
But maybe I wasn't saying it as clearly?
My apologies ;-).
> The other (3) cd's would include all the other packages that are
> currently in fedora core 2, and should be listed and described in the
> comps / rpmdb-fedora packages.
> Then if you do a clean install it would only use the first CD to do
> the basic install, run thru first-boot, and allow people to add
> additional packages from either the 3 extra's cd's (it would know
> where they are and ask for the correct cd by looking that up in the
> comps / rpmdb-fedora lists), or offer the option to download them from
> a selected mirror.
> However if you do an upgrade using the first cd, it can use the
> knowledge of what packages are on what cd's to include those in the
> upgrade, and do a clean and sound upgrade (asking for those cd's as it
> does now).
> As far as i can think off thats the only way to satisfy the upgrade
> cycle dependency, while allowing for a 1 core cd install.
Now you're seeing it my way!
Thank you for re-iterating it in another way.
Maybe now others will see it as you do.
> Ofcource then the question becomes "What packages do we include on the
> core cd". To be able to play around with that question i've written a
> little tool in PHP which i've posted in a seperate email (Subject: A
> usefull tool (Was: Making Fedora Core CD #1 Standalone)).
Right, and I'm going to start play with it.
> You would be supprised at how much you can still include on the first
> CD.. With that tool you can show that all this paranoia about "Don't
> include any, *0* apps on the core CD" is being overly zealous..
Well, I'm anal. I'm thinking of the company that has its own, internal
Apt repository. So it's easy to fetch what you need for different
systems. Eventually the company should write its own comps.xml, but
this "Quark" gives them a "nice base."
Eventually I'd like to see the "Quark" weed out a lot of stupid,
unnecesary dependencies in "Core." But that's a future ideal.
> Your able to fit quite a large collection of workstation and server
> packages on one CD.. The mix that i came up with playing with the
> dep-tree tool is:
> ./dep-tree.php -d firstboot system-config-packages mozilla yum rpm
> mdadm cups vixie-cron httpd samba jfsutils php perl usbutils
> isdn4k-utils irda-utils metacity gnome-desktop gnome-session
> gnome-panel compat-db compat-libstdc++ compat-glibc openssh
> openssh-server openssh-clients openldap samba screen magicdev
> openmotif xmms gedit lm_sensors ntp gnome-utils autofs setserial nmap
> mgetty stunnel curl eject nautilus-cd-burner nautilus-media lsof wget
> telnet ftp gnome-applets gftp openoffice.org gimp gaim links mkinitrd
> mktemp ttmkfdir mkbootdisk xpdf eog gcc autoconf automake15
> autoconf213 automake automake14 make
> Number of packages: 457
> Total size installed: 1557 Mb
> Total packaged size: 498 Mb
> So this includes (i think) all the basic packages for a working linux
> instalation, qt/gnome/kde/motif compatiblity, mozilla, gimp, gaim,
> openoffice and lots of other workstation apps, and all required basic
> server apps (webserver, openssh, telnet, ftp, yum, nmap, screen, wget,
> links etc)
I'd go the other way. No apps. Why? Because in short order, it will
bloat to more than 1 CD. The idea here is to make it as small as
possible. Even if its only 300MB or smaller.
Someone can _always_ "fill" the official "Core" CD #1 with more -- but
it all starts with the "Quark" comps.xml _first_, as the "base." We
need more than the 90MB one (although that's not a bad start).
BTW, does that list include Kerberos? I probably need to find out by
using RPM-Analyzer.
> The nice thing of this is that the first CD can then offer 4 install modes:
> - Basic Workstation
> - Basic Server
> - Both server and workstation software
> - Minimal instalation (90 or so megs, already included in FC1/2)
> [x] checkbox Include development packages and tools
I see little reason to include development. They can be fetched via Apt/Yam.
For those that can't, Quark is not for them. They should install the full
"Core" instead (possibly from 3rd party DVD with Extras added).
> While still offering a fully functional end result, and including all
> *-devel packages and compilers so the system is self-building and
> allows you to compile kernels, source rpm's or tarbals (imho it would
> go against the spirit of *nix / open source to have a system that
> could not compile software or it's self)
But at what point do you start not including stuff? I say devel is out
for "Quark." You have Apt/Yam to fetch them anytime you need.
> Then if they want all KDE apps, more server software, a slow of perl-*
> packages, databases, then the extra 3 cd's come into play (and/or
> external repositories)
Here's what I think should be in "Quark" (or whatever it is called):
- Everything in "Minimal Install" (90MB)
This is a suppport consideration
- All client network services for basic X/GNOME functionality
- All client probing/hardware support
Everything from DHCP to Mozilla, and the GTK+/GNOME to run it
This includes Fonts (which can quickly be a size issue)
- All directory service, authentication, crypto clients/services
- All network client/services having to do with file
Because if you can't connect to any network setup, you can't fetch
And that's all. No extra GNOME applets or goodies. No bitmaps other
than maybe the Fedora one. No frills. Those can be apt-get'ted.
In an enterprise environment, I'd rather have a "base" install like
Quark on a CD, and then run a script that does an "apt-get" of
everything else needed. But that's just me.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months
Re: Making Fedora Core CD #1 Standalone -- Goals of "Quark"
by Bryan Smith
Jeff Spaleta wrote:
> Do some research... a lot of this ground was covered in pre-fc1
> discussions on the mailinglists... look for threads about minimal
> install...
Right. I've been looking through some of this already.
> Aug/Sep 2003 archive in fedora-test-list would probably be of interest
> to you if you plan to incorporate other community opinion in your
> master plan about better minimal base.
Yes. I'm already formulating the official "goals." I have to have those
in-place before I can build a rationale for the comps.xml and package list.
So far I have:
1. Establish "minimum" inter-dependency in a "minimum" install,
including identifying poor interdependencies in basic "Core" packages
2. Establish a "bare" network client/server install, but with
full, modern access, directory and authentication support.
3. A bare, no frills network/GUI install (no applications)
4. A "common denominator" for not only all subsequent package sets,
but an "aim point" for developers creating new GUI applications
#4 is what I keep coming back to. If I'm developing a new GUI
application, what components _should_ I "aim for" -- that I
_know_ will be on _all_ systems?
Right now we have little more than the full, 4 CD "Core."
There's nothing wrong with that looking from legacy RHL upward.
But there is a good reason to start "afresh."
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months
Re: Making Fedora Core CD #1 Standalone -- Core should continue, but let's define a subset
by Bryan Smith
Chris Chabot wrote:
> Actually that makes me wonder though what this 'core' is of fedora.
> I've seen this core concept mentioned many times in this thread, and
> most ppl do seem enthusiastic about the concept (though there are
> obvious bariers to overcome, problems to solve etc). However i
> haven't seen anyone explain what -they- see as a core.
Well, I'm sure I have confused many.
To start, let me tell you what I think, and where I am coming from.
1. I consider Fedora Core to be Red Hat Linux
2. Fedora Core will bloat to 5, 6 and more CDs
As such, all the legacy needs to be in it, along with anything new.
There is no way to avoid this, without breaking compatibility and
assumptions. Is it a bad thing? That's debateable. There is much
good to adding more and more as part of the "full" install,
Scribus, OpenGroupware.org (OGo), Firefox/Thunderbird, etc...
Now many have suggested, heck I even started out by taking Pritchard's
post, about "rolling back" the size of Fedora Core. Talk of moving
things to Extras, or elsewhere. But by the very nature of Core v.
Extras, there may be legacy/compatibility issues to consider. And
as many have stated, there is the fact that some people want a
full install from media, since Internet bandwidth is still a
premium in many parts of the US (let alone many places outside the US).
So what I'm considering is not touching Core itself. Instead, let's
define the "absolute minimum" of Core. If we can do this by making
sure it is the CD #1 in Core, then it will have minimal impact. If
we need to do it by defining a set of "rules" -- maybe a "sub-
repository" that is still part of Core, but has the contraints that
no package requires any additional Core packages not in it, then
let's do it. I proposed the name "miniCore" or "Quark," but that's
just a temporary reference I make.
So, onto defining what is in "Quark" ...
> A xorg, gnome basics, system-config-packages etc is all nice and
> dandy, but ppl who want to setup a server without X would not be
> pleased by this system at all.
> Or if was a workstation, and the core CD only had those core apps,
> wouldnt you always need the extra's cd's? (for say openoffice,
> mozilla, or whatever is needed)
It's hard to "please everyone." Let's not try to break up Fedora
Core into different CDs for different users. That's a headache
that will only add to the burden. I'm all about minimizing the
packaging burden. Besides, with Fedora's new, distributed nature,
it is not necessary.
No, what I'm talking about is _ultra_basic_ stuff. A basic server.
A basic workstation. _No_ applications. _No_ feature rich services.
You get X and GNOME, *0* apps. Not even the standard GNOME app spread.
You get basic services, enough for a basic file, print or web server,
but with _no_ riches.
And we _really_ need to start defining the _basic_ scripting support
required in Perl, Python and/or PHP, etc... Otherwise, the bloat is
only going to get worst in packages. Yes, it's hard to do it now, but
let's at least _define_ the "recommendations," like Debian did long
ago.
For example, packages that require Emacs _only_ because it runs some
Lisp or other interface for just the package script -- stuff like that
has just got to end. Now we can't do it overnight with Core. Trying to
do so would only break compatibiltiy and cause additional re-engineering
headaches.
But by defining a new set of rules for including in "Quark," we
can lay a new foundation. If you're going to be part of the "Quark"
cornerstone of Fedora, you have to adhere to X, Y and Z. It won't
happen overnight, but luckily we can start by making Quark minimal
in design.
I'm sure in 3-5 years, Quark will bloat, and then we'll need a
"sub-Quark" to refresh it. As you may note, the idea here is not to
"reduce" Core, but to slowly replace it with a smaller standard.
Because things bloat. God, if there is one "bad habit" the social
design has, it is the tendency to add yet more and more and more
until many people forget about various things available (there is
no more proof than that the ultimate social design, governments ;-).
So the "workaround" is to let what exists be, but slowly move
people towards a new, smaller version.
> Another question, is there a seperate development cd? (auto*, gcc*
> kernel-source, etc), or is that considered core functionality?
Again, let's not over-complicate this. Remember, I'm all about
_minimal_impact_ and _minimal_re-engineering_ effort.
In a nutshell, let's just let "Core" be as it is. A slowly bloating
reference. With Apt/Yam, we can yank what we need over the Internet.
For those with limited bandwidth, well, they'll just want the full Core.
But for those that want to "start simple," that's what Quark will be.
At least until 3-5 years later when Quark has now bloated. ;-ppp
Ahhh, someone could write a thesis on the natural occurrance of
bloat in software distribution! The key is to not fight the bloat,
as that only breaks compatibility and assumptions. The key is to
introduce a new, smaller distribution until it bloats, and then
another, etc...
So I'm suggesting we do that with "Quark." A sub-set of Core that
is just enough to get a basic file/print/web server running, or a
X workstation with just the bare GNOME interface. Nothing more.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months
Re: Making Fedora Core CD #1 Standalone -- Core should continue but let's define a subset
by Bryan Smith
Chris Chabot wrote:
> This actually opens a whole new can of worms for the fedora project..
> Most of these plans should really be split into 3 different
> repositories:
> - Supported Core
> - Support additional packages
> - Unsupported additional packages
Is that not Fedora "Core" "Extras" (and "Alternatives") and "3rd party"
now? Why reproduce what _does_ work _now_?
I'm not questioning Red Hat's selection/repository as it is build atop
of Core. And I'm not really even questioning Core itself.
I'm must saying that (as someone else pointed out), the "comps.xml"
could use some play. That is where I have focused my efforts in the
past (from RHL 7 upward).
> That way the core is a solid base on which to base everything else.
> The supported packages would be bugzilla'ble and would either be
> maintained by Redhat or by a trusted maintainer (who has earned this
> title and trust over time in the unsupported playground) and the
> unsupported would be a great place for well working packages that are
> not maintained by a trusted maintainer or redhat.
But at some point Core is going to be overbloated (some said RHL 7 was
;-). You get no argument from me behind the reasoning -- legacy/upward
compatibility. But there should probably be an attempt to create a new,
"subset" that people can choose that just gives them a running system.
> This way anyone can try to contribute packages (as u said, for things
> like OpenGroupWare.org, etc) and the maintainer can prove and show he
> can maintain, fix and support this contribution over time before it
> gets moved to 'officialy included'. in essence this follows the debian
> structure, packages are only included if there is a valid and trusted
> maintainer for them.
No, I'm not saying that (did I even say that?). I don't question the
Fedora steering committee on the selection for Core, Extras, etc... I
trust their good judgement to continue Core, Extras, etc... on the path
it is going. To do otherwise is only a distraction and a lot of useless
effort. After all, Fedora is distributed now -- or someone gets Core
plus Extras on a single DVD because they have low bandwidth.
I'm just suggesting it might be time to define a "basic" subset for
Core. With the distributed repositories and dependency checking, any
thing that needs to be install can be installed.
> Reasoning for this is that it would be a _lot_ worse if there was a
> serious data-destroying bug or security compromising bug in a package
> that no one would fix (in a timely and correct fashion) then it would
> be to not include a package.
I don't think I've ever suggested this. I think you're making a
statement based on what you think I suggested, but did not.
Trying to replicate the package and support decisions of the RH/Fedora
team would be ludicrious. And it's unnecessary with the distributed
repositories nowdays.
As someone else pointed out, all I'm saying is that it might be time
for a "tighter" comps.xml as just an _option_ for a CD.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months
Re: Reduce "Core" to 1 Binary CD? -- Don't change Core, but make CD #1 "standalone"
by Bryan Smith
[ BTW, should this be on "users" instead? My apologies if so. ]
I've seen a lot of good arguments here, from many angles. The fact that
people don't have high-speed connections, the issues with moving stuff
to Extras, etc...
Basically, what I'm saying is that we probably should touch "Core."
What is in "Core" is done. There is no sense trying to remove bloat.
We're just going to run into dependency hell.
But at what point shouldn't be consider maybe making a "Core subset"?
One that fits on a single CD. It would not only be a standalone CD, but
it would also be Fedora Core CD #1 itself.
Surely we could fit a lot of functionality on a single CD. Just the
basic utilities, X, GNOME and a few other things. Just enough to get up
and running. For those of us that might have a fast Internet
connection. Or maybe we just want a "bare bones" install.
Heck, it might simply distribution altogether. You'd just have:
1 CD Version: Fedora Quark (or whatever you'all call it)
1 DVD Version: Fedora Core (Quark CD #1 + all other CDs)
And for those that want the full CD set, the DVD version would include a
script to remaster all into CDs. That way Red Hat could expedite
pushing to mirrors with a _single_ DVD .iso, that is then remastered
into both the CD .isos and ./os directories locally with that script.
Imagine all the reduced traffic. And now some mirrors might just have
"Quark" instead of the full "Core," for users that do want to pull their
own, select packages.
Just an idea. It could solve a lot of issues.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
19 years, 11 months