9:07 p.m.
Hey list, Jeremy and Bill,
Sorry for being slow in reviewing patches; most of my time past two
month been spent traveling and working on other features on Fedora 7.
Enough with bad excuses. Anyway, looks like Jeremy and Bill been kicking
ass writing patches so I've merged them all into master.
Also, the livecd repo is now located here rather than on freedesktop.org
http://git.fedoraproject.org/?p=hosted/livecd
The HACKING file for instructions on how to checkout the code is updated
http://git.fedoraproject.org/?p=hosted/livecd;a=blob;f=HACKING;hb=HEAD
Btw, Jeremy, where can I find a kickstart file? Also, should we include
a simple works-for-latest-distro example kickstart file in the repo
along with comments on how to use it? Also, for Fedora, where do you
envision will we store such Kickstart configuration files? In an SCM of
some sort I presume?
Will we have separate kickstart files per arch? I presume we want the
package selection to differ for x86_64, ppc and x86, just by virtue that
it's going to be larger for the former two. Can Kickstart do this
already?
David
8:56 a.m.
On Monday 05 March 2007 22:07:33 David Zeuthen wrote:
Also, for Fedora, where do you
envision will we store such Kickstart configuration files? In an SCM of
some sort I presume?
This is a problem I have to solve for pungi as well. I'd like to keep the
config file/manifest file somewhere in public scm, but I keep running into a
brain block when thinking about what to name such a repo. We have comps, I'm
half way tempted to make a new repo that has a comps/ subdir, a compose/ and
a livecd/ or something like that and call it fedora-compose or some such.
Just thinking out loud.
Will we have separate kickstart files per arch? I presume we want
the
package selection to differ for x86_64, ppc and x86, just by virtue that
it's going to be larger for the former two. Can Kickstart do this
already?
By just listing various groups from comps, you can have a singular package
set. Some of the packages won't be available on some arches and that's ok,
the tool should allow for that. Warn about missing packages but don't error
out. Really the only thing that differed in my kickstart files from arch to
arch was the source of the install, and I made that a stub that was included
into a singular unified kickstart file. I'm pretty sure we can have just one
ks file for all the arches.
--
Jesse Keating
Release Engineer: Fedora
10:31 a.m.
On Tue, 2007-03-06 at 09:56 -0500, Jesse Keating wrote:
On Monday 05 March 2007 22:07:33 David Zeuthen wrote:
> Also, for Fedora, where do you
> envision will we store such Kickstart configuration files? In an SCM of
> some sort I presume?
This is a problem I have to solve for pungi as well. I'd like to keep the
config file/manifest file somewhere in public scm, but I keep running into a
brain block when thinking about what to name such a repo. We have comps, I'm
half way tempted to make a new repo that has a comps/ subdir, a compose/ and
a livecd/ or something like that and call it fedora-compose or some such.
Just thinking out loud.
Let's just do it and not over-analyze it for now. Stick it
under /cvs/fedora and then it's nice and simple.
Jeremy
1 p.m.
On Tue, 2007-03-06 at 11:31 -0500, Jeremy Katz wrote:
On Tue, 2007-03-06 at 09:56 -0500, Jesse Keating wrote:
> On Monday 05 March 2007 22:07:33 David Zeuthen wrote:
> > Also, for Fedora, where do you
> > envision will we store such Kickstart configuration files? In an SCM of
> > some sort I presume?
>
> This is a problem I have to solve for pungi as well. I'd like to keep the
> config file/manifest file somewhere in public scm, but I keep running into a
> brain block when thinking about what to name such a repo. We have comps, I'm
> half way tempted to make a new repo that has a comps/ subdir, a compose/ and
> a livecd/ or something like that and call it fedora-compose or some such.
> Just thinking out loud.
Let's just do it and not over-analyze it for now. Stick it
under /cvs/fedora and then it's nice and simple.
Also the repositories shouldn't be defined in the kickstart file, no? I
expect that people pass them on the command line to livecd-creator and,
I presume, to pungi too. Yes?
David
3:22 p.m.
On Tuesday 06 March 2007 14:00:03 David Zeuthen wrote:
Also the repositories shouldn't be defined in the kickstart file,
no? I
expect that people pass them on the command line to livecd-creator and,
I presume, to pungi too. Yes?
Pungi does not have the capability yet to define a repo on the cli. I tried
to keep the cli options to a minimum so that it was simple and things were
defined in config files. That said, I suppose one could define repos at the
cli, but I'd get really tired of typing in 2*N repos (one binary, one source)
for each "repo" I wanted to use (Core, Extras, That which shall not be named)
For that reason, the config files I'd stash in there would be genericized to
point at say the mirror list for Core and Extras, whereas the one used
internally may point to an internal mirror, or something like that.
--
Jesse Keating
Release Engineer: Fedora
3:38 p.m.
On Tue, 2007-03-06 at 16:22 -0500, Jesse Keating wrote:
That said, I suppose one could define repos at the
cli, but I'd get really tired of typing in 2*N repos (one binary, one source)
for each "repo" I wanted to use (Core, Extras, That which shall not be named)
For testing, I just have a script that invokes the tool with my chosen
command line options e.g. my local repositories.
Also, we can add more sugar to the programs as needed, e.g. perhaps
interactively prompt for the user to add repositories, make the program
use a mirror list, add an option to use the default repos for release N,
use the repos that is specified as active in /etc/yum.repos.d (or
elsewhere) etc. etc.
For that reason, the config files I'd stash in there would be
genericized to
point at say the mirror list for Core and Extras, whereas the one used
internally may point to an internal mirror, or something like that.
Ugh, that sounds really painful. I think, in general, the main point is
that we don't want the users to edit these files, we want users to trade
such files with each other and so forth.
I guess, to illustrate my point, what I like to be able to
# livecd-creator --config=http://foo.bar/rawhide/livecd-desktop.ks
--repo=dev,file:///Repos/core
--repo=dev,file:///Repos/extras
# livecd-creator --config=http://foo.bar/rawhide/livecd-desktop.ks
--use-system-repos
# livecd-creator --config=http://foo.bar/rawhide/livecd-desktop.ks
--use-repos-from=~/repos/local-rawhide.d
# livecd-creator --config=http://foo.bar/6/livecd-desktop.ks
--use-repos-from=~/repos/local-fc6.d
to spin a live cd. Hope this clarifies.
David
3:48 p.m.
On Tuesday 06 March 2007 16:38:09 David Zeuthen wrote:
For testing, I just have a script that invokes the tool with my
chosen
command line options e.g. my local repositories.
I do too, my chosen URLs being in the config file (:
Also, we can add more sugar to the programs as needed, e.g. perhaps
interactively prompt for the user to add repositories, make the program
use a mirror list, add an option to use the default repos for release N,
use the repos that is specified as active in /etc/yum.repos.d (or
elsewhere) etc. etc.
Wouldn't that kind of suger be best in a graphical UI? You'd want the backend
to be straight and simple, with interactiveness built into a gui app that
calls things from the backend, that way you could have a gui gtk front end, a
web front end, etc...
> For that reason, the config files I'd stash in there would
be genericized
> to point at say the mirror list for Core and Extras, whereas the one used
> internally may point to an internal mirror, or something like that.
Ugh, that sounds really painful. I think, in general, the main point is
that we don't want the users to edit these files, we want users to trade
such files with each other and so forth.
I guess, to illustrate my point, what I like to be able to
# livecd-creator --config=http://foo.bar/rawhide/livecd-desktop.ks
--repo=dev,file:///Repos/core
--repo=dev,file:///Repos/extras
# livecd-creator --config=http://foo.bar/rawhide/livecd-desktop.ks
--use-system-repos
# livecd-creator --config=http://foo.bar/rawhide/livecd-desktop.ks
--use-repos-from=~/repos/local-rawhide.d
# livecd-creator --config=http://foo.bar/6/livecd-desktop.ks
--use-repos-from=~/repos/local-fc6.d
to spin a live cd. Hope this clarifies.
I get what you're saying, but if the common example is using core and extras
repos, why not default to those in a config file? I can see adding the
ability to override that at the cli, and maybe I'll do that for pungi at some
point, but what I expect people to trade around or fiddle with for pungi is
the package set, and the name. A shared config that everybody uses doesn't
strike me as useful if everybody is just creating the same thing. I want
people to create something different and that requires changing the
configuration.
--
Jesse Keating
Release Engineer: Fedora
4:11 p.m.
On Tue, 2007-03-06 at 16:48 -0500, Jesse Keating wrote:
I get what you're saying, but if the common example is using core
and extras
repos, why not default to those in a config file? I can see adding the
ability to override that at the cli
Overriding the repo URL via the CLI is actually be the best solution.
I want
people to create something different and that requires changing the
configuration.
I don't want people to edit configuration files (in fact I want the
tools to be able to download the config file via http so it's easy to
track the changes to the configuration) just to use a local mirror on
their hard disk.
Realistically everyone but you and perhaps myself will have to use a
local mirror on their hard disk. And I don't think it's fair to require
people to edit a configuration file as they will have to redo these
changes every time they want to get the latest revision of the config
file. Sure, for pungi maybe it won't change but for livecd it will go
through a lot of churn as we add/remove packages to put as much useful
stuff on ISO that is constrained by 700MB.
David
7:39 p.m.
On Tuesday 06 March 2007 17:11:25 David Zeuthen wrote:
I don't want people to edit configuration files (in fact I want
the
tools to be able to download the config file via http so it's easy to
track the changes to the configuration) just to use a local mirror on
their hard disk.
Realistically everyone but you and perhaps myself will have to use a
local mirror on their hard disk. And I don't think it's fair to require
people to edit a configuration file as they will have to redo these
changes every time they want to get the latest revision of the config
file. Sure, for pungi maybe it won't change but for livecd it will go
through a lot of churn as we add/remove packages to put as much useful
stuff on ISO that is constrained by 700MB.
I don't think you're getting the point. Without editing a config file, the
only thing users are able to do is reproduce what we're already doing, and
that isn't very interesting at all. Making real changes involves editing
config files, changing the manifest, changing the name, changing what the
system does upon install, all things not easily done via cli arguments. For
that reason, I designed pungi to mostly work from config files, and only a
few convenience things made capable via cli arguments.
--
Jesse Keating
Release Engineer: Fedora
8:52 p.m.
On Tue, 2007-03-06 at 20:39 -0500, Jesse Keating wrote:
I don't think you're getting the point. Without editing a
config file, the
only thing users are able to do is reproduce what we're already doing, and
that isn't very interesting at all. Making real changes involves editing
config files, changing the manifest, changing the name, changing what the
system does upon install, all things not easily done via cli arguments. For
that reason, I designed pungi to mostly work from config files, and only a
few convenience things made capable via cli arguments.
You ought to at least provide a way to override the repo.
Anyway, I do think that I get the point, but I guess we just don't share
the same design philosophy about what's easy for users - probably
because livecd-creator and pungi cater to different classes of users.
They are different thins. Anyway, for the former I made it an explicit
goal that you could do these things on the command line:
- set live CD name
- add/remove packages
- use different repositories so you can quickly make it pull in
mydistro-logos (that provides: system-logos) instead of e.g.
fedora-logos etc.
- there will be a --shell option so you can poke around and do
post-configuration changes. Probably a --post-script option too
so you can run a script in the chroot post-config
- there's a --base-on to put extra packages on an existing live cd /
poke around via --shell / --post-script
since this is what Joe Enduser wants to do.
Also keep in mind that live cd kickstart files are going to change *a
lot* more often that spin kickstart files, mostly because we want to get
as close to 700MB of content (without spilling over!) and packages
change all the time.
Therefore, it's a lot more important that users don't have to edit some
file as he will run into merge problems the next time he attempts to
synchronize with the upstream provider of the live cd kickstart file.
Hope this clarifies.
David
12:47 p.m.
On Tue, 2007-03-06 at 21:52 -0500, David Zeuthen wrote:
since this is what Joe Enduser wants to do.
No. Joe Enduser wants to download a CD and use it. Or maybe use a web
UI to create a live CD on a remote server and then download it.
Joe Enduser does not want to pass command line arguments to a tool.
Jeremy
9:02 p.m.
--- Jeremy Katz <katzj(a)redhat.com> wrote:
On Tue, 2007-03-06 at 21:52 -0500, David Zeuthen wrote:
> since this is what Joe Enduser wants to do.
No. Joe Enduser wants to download a CD and use it. Or maybe use a
web
UI to create a live CD on a remote server and then download it.
Joe Enduser does not want to pass command line arguments to a tool.
I somewhat disagree with this. I think it's a mistake to forget about
the fact that many Joe (and Jane :) Endusers of a livecd generation
system will be the sorts of people that either do understand things
like an xterm in a little more detail, or want to learn.
IMO part of the power of linux, in addition to the source code, is the
command line. The command line is the place where you leverage your
imagination and a wide variety of tools to create new things rapidly.
I know this isn't exactly the RH party line, but no one has ever been
able to count on me towing the(any) party line. I think the fact that
microsoft is bringing a powerful shell/terminal back into their OS
shows that even they understand this a little.
But getting back on point- You mention Joe Enduser building a livecd
on a remote server with a web UI? What makes you think they want to do
this when there is no reason they couldn't build it on the local system
with the exact same web(or other graphical) UI? Here is an example of
what I think the first thing Jane Enduser wants to do-
livecd-generator \
--make_me_a_livecd_just_like_this_template=knoppix-5.0 \
--but_with_these_two_apps_I_like=emacs,xmms \
--and_go_ahead_and_pull_in_latest_security_updates \
--outputfile=./mylivecd.iso
Now clearly, most, (though I would argue not a _vast_ majority) would
want to do this via a GUI that provides a nice list of pre-existing
templates, and a nice list of available packages (i.e. pup gui).
But I definitely think a signifigant number of (especially the early)
end users of a livecd generator would like to be able to do anything
from a commandline(+configfiles) (CRON... COUGH... CRON... COUGH...)
that they can do from the GUI.
Just 2 more cents because I think our future depends on at least a few
hobbyists learning to wield the full force of the command line. (and
free speech, but thats a different war)
-dmc/jdog
____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
12:47 p.m.
On Tue, 2007-03-06 at 16:38 -0500, David Zeuthen wrote:
On Tue, 2007-03-06 at 16:22 -0500, Jesse Keating wrote:
> That said, I suppose one could define repos at the
> cli, but I'd get really tired of typing in 2*N repos (one binary, one source)
> for each "repo" I wanted to use (Core, Extras, That which shall not be
named)
For testing, I just have a script that invokes the tool with my chosen
command line options e.g. my local repositories.
How is this any better than having a file that you just pass as an
argument to livecd-creator? I'd say it's _worse_ because you have both
a script and a config that you're maintaining.
Also, we can add more sugar to the programs as needed, e.g. perhaps
interactively prompt for the user to add repositories, make the program
use a mirror list, add an option to use the default repos for release N,
use the repos that is specified as active in /etc/yum.repos.d (or
elsewhere) etc. etc.
I think that a lot of the sugar like this should sit at a higher level
and generate the config. One tool for one job. If the lowlevel
livecd-creator bits have to handle all of this, then it just becomes
that much harder to get consistent and reliable output from the tool.
And to do things like integrate it with the buildsystem/rawhide pushes.
In fact, if we have it so that everything about what was used to create
the live CD is in the config file, then we can (and arguably should)
also include the config _on_ the CD. But if there's a combination of
config file plus whatever arguments someone happened to pass that day,
then it's a lot harder to do that.
> For that reason, the config files I'd stash in there would
be genericized to
> point at say the mirror list for Core and Extras, whereas the one used
> internally may point to an internal mirror, or something like that.
Ugh, that sounds really painful. I think, in general, the main point is
that we don't want the users to edit these files, we want users to trade
such files with each other and so forth.
Actually, I want users to share their actual outputs. And have the
output be fully reproducible without having to know exactly what
arguments I used to a tool
Jeremy
10:27 a.m.
On Mon, 2007-03-05 at 22:07 -0500, David Zeuthen wrote:
Sorry for being slow in reviewing patches; most of my time past two
month been spent traveling and working on other features on Fedora 7.
Enough with bad excuses. Anyway, looks like Jeremy and Bill been kicking
ass writing patches so I've merged them all into master.
Cool, sounds good.
Btw, Jeremy, where can I find a kickstart file?
I sent one with the initial kickstart patch. My current one doesn't
quite fit on a CD as I try to make it have roughly the same package set
as the default distro install does.
Also, should we include
a simple works-for-latest-distro example kickstart file in the repo
along with comments on how to use it?
Yep, we definitely should. I'll try to get some of the README bits and
the like updated over the next day or so.
Will we have separate kickstart files per arch? I presume we want
the
package selection to differ for x86_64, ppc and x86, just by virtue that
it's going to be larger for the former two. Can Kickstart do this
already?
There's no real reason that the kickstart config _has_ to be
different... size for ppc shouldn't be significantly different. On
x86_64, doing a CD sized image is perhaps killing ourselves when we
shouldn't given the download numbers for CD vs DVD on x86_64. And we
don't want to reach the point where there aren't any useful apps on the
image.
Jeremy
12:26 p.m.
On Tue, 2007-03-06 at 11:27 -0500, Jeremy Katz wrote:
On Mon, 2007-03-05 at 22:07 -0500, David Zeuthen wrote:
> Sorry for being slow in reviewing patches; most of my time past two
> month been spent traveling and working on other features on Fedora 7.
> Enough with bad excuses. Anyway, looks like Jeremy and Bill been kicking
> ass writing patches so I've merged them all into master.
Cool, sounds good.
> Btw, Jeremy, where can I find a kickstart file?
I sent one with the initial kickstart patch. My current one doesn't
quite fit on a CD as I try to make it have roughly the same package set
as the default distro install does.
I tried this last night but livecd-creator fails without useful error
messages.. and cleanup don't work so I'm left with /dev/loop0 which is
mounted and I have to clean up by hand. Not to sound like a whiner
(though I probably am) but please fix look into this and make sure that
HEAD don't contain such errors in the future. HEAD should always be
working.
(FWIW, I think this is because yum is throwing exceptions left and right
when adding groups and packages.)
Yep, we definitely should. I'll try to get some of the README
bits and
the like updated over the next day or so.
Sounds good thanks.
> Will we have separate kickstart files per arch? I presume we
want the
> package selection to differ for x86_64, ppc and x86, just by virtue that
> it's going to be larger for the former two. Can Kickstart do this
> already?
There's no real reason that the kickstart config _has_ to be
different... size for ppc shouldn't be significantly different.
My tests some months ago showed this was the case though - around 20%
which is something we shouldn't ignore...
On
x86_64, doing a CD sized image is perhaps killing ourselves when we
shouldn't given the download numbers for CD vs DVD on x86_64. And we
don't want to reach the point where there aren't any useful apps on the
image.
Do we want to include 32-bit packages at all for x86_64? I don't see why
we would... what's the rationale?
Btw, you didn't answer my question though- can you do package selection
in kickstart based on what arch it is?
David
3:26 p.m.
On Tuesday 06 March 2007 13:26:05 David Zeuthen wrote:
I tried this last night but livecd-creator fails without useful
error
messages.. and cleanup don't work so I'm left with /dev/loop0 which is
mounted and I have to clean up by hand. Not to sound like a whiner
(though I probably am) but please fix look into this and make sure that
HEAD don't contain such errors in the future. HEAD should always be
working.
(FWIW, I think this is because yum is throwing exceptions left and right
when adding groups and packages.)
You're running this on fully updated rawhide yes?
Do we want to include 32-bit packages at all for x86_64? I don't
see why
we would... what's the rationale?
Given that the user can install packages to the liveCD, and that they are left
with what is on the LiveCD once they install the system, and may want to use
32bit software, we should offer some ability to take advantage of their
x86_64/32bit capability.
Btw, you didn't answer my question though- can you do package
selection
in kickstart based on what arch it is?
I don't believe so.
--
Jesse Keating
Release Engineer: Fedora
3:43 p.m.
On Tue, 2007-03-06 at 16:26 -0500, Jesse Keating wrote:
You're running this on fully updated rawhide yes?
Yea, I did update the system before trying. It's 32-bit fwiw.
> Do we want to include 32-bit packages at all for x86_64? I
don't see why
> we would... what's the rationale?
Given that the user can install packages to the liveCD, and that they are left
with what is on the LiveCD once they install the system, and may want to use
32bit software, we should offer some ability to take advantage of their
x86_64/32bit capability.
I don't really get this... so you want to add 32-bit packages to a
64-bit live cd... just so they don't have to pull in 32-bit base
packages (such as glibc) when installing a 32-bit app? What pieces of
software did you have in mind?
So I guess I'm suggest to just install 64-bit packages and don't bother
pulling in any 32-bit packages until they're needed. What's wrong with
that?
> Btw, you didn't answer my question though- can you do
package selection
> in kickstart based on what arch it is?
I don't believe so.
Perhaps that's something it needs to do. We're going to end up seeing
size differences in ISO files for archs. For example x86 livecd may be
30MB smaller than ppc livecd; that space can and should be used for
something useful such as more themes, more promotional materials or
whatever.
David
4:07 p.m.
On Tuesday 06 March 2007 16:43:53 David Zeuthen wrote:
I don't really get this... so you want to add 32-bit packages to
a
64-bit live cd... just so they don't have to pull in 32-bit base
packages (such as glibc) when installing a 32-bit app? What pieces of
software did you have in mind?
I don't really know off hand, it's more about being consistant between the
LiveCD (+install) and what we do for a regular install. I'd hate to see the
LiveCD experience drift more and more to the point that they aren't
comparable. I really don't know what people will try to do with a LiveCD,
particularly an x86_64 one.
So I guess I'm suggest to just install 64-bit packages and
don't bother
pulling in any 32-bit packages until they're needed. What's wrong with
that?
Other than it is completely differnet from what we do for a regular install...
I really don't know.
> > Btw, you didn't answer my question though- can you do
package selection
> > in kickstart based on what arch it is?
>
> I don't believe so.
Perhaps that's something it needs to do. We're going to end up seeing
size differences in ISO files for archs. For example x86 livecd may be
30MB smaller than ppc livecd; that space can and should be used for
something useful such as more themes, more promotional materials or
whatever.
I'd like to see some actual attempts at these other arches to see what the
size differences are before we go too far off into the weeds of trying to
define a different package set for each arch.
--
Jesse Keating
Release Engineer: Fedora
4:16 p.m.
On Tue, 2007-03-06 at 17:07 -0500, Jesse Keating wrote:
> So I guess I'm suggest to just install 64-bit packages and
don't bother
> pulling in any 32-bit packages until they're needed. What's wrong with
> that?
Other than it is completely differnet from what we do for a regular install...
I really don't know.
So perhaps we should just do it for Test3 (if we do an x86_64 live cd)
and wait for people to file bugs / complain. Unless someone comes up
with real examples on why it's useful to include both 32- and 64-bit
packages I only see this as a waste of space and I'd hate to waste space
because "that's what we do for regular installs" :-)
(Btw, why do we include 32-bit packages nowadays for regular installs in
the first place? I never was able to figure that out, except for the
fact that OO.o was 32-bit only. As that is no longer the case perhaps
that decision needs to be revisited too.)
I'd like to see some actual attempts at these other arches to see
what the
size differences are before we go too far off into the weeds of trying to
define a different package set for each arch.
Sure, that's sensible. We need data.
David
7:42 p.m.
On Tuesday 06 March 2007 17:16:50 David Zeuthen wrote:
(Btw, why do we include 32-bit packages nowadays for regular installs
in
the first place? I never was able to figure that out, except for the
fact that OO.o was 32-bit only. As that is no longer the case perhaps
that decision needs to be revisited too.)
I've heard it was for convenience of those wanting to run 32bit 3rd party
binaries, and for those that want to do cross-arch development. However with
things like mock that becomes less of a use case. It is a _little_ odd to
exclude i386 packages when doing x86_64 installs, but not afterward so that
if somebody tried to install a 32bit package, yum would be able to
find/install the 32bit deps.
It gets more interesting when you consider ppc/ppc64 where when you have ppc64
hardware you only want a FEW ppc64 packages but mostly ppc32 packages
installed, so if we made something more convenient for x86_64 we'd have to do
something completely different for ppc64. This just takes more work, and not
work that I have time to do for this release, nor do I imagine the installer
folks have time to do either.
--
Jesse Keating
Release Engineer: Fedora
12:47 p.m.
On Tue, 2007-03-06 at 16:43 -0500, David Zeuthen wrote:
On Tue, 2007-03-06 at 16:26 -0500, Jesse Keating wrote:
> > Do we want to include 32-bit packages at all for x86_64? I don't see why
> > we would... what's the rationale?
>
> Given that the user can install packages to the liveCD, and that they are left
> with what is on the LiveCD once they install the system, and may want to use
> 32bit software, we should offer some ability to take advantage of their
> x86_64/32bit capability.
I don't really get this... so you want to add 32-bit packages to a
64-bit live cd... just so they don't have to pull in 32-bit base
packages (such as glibc) when installing a 32-bit app? What pieces of
software did you have in mind?
So I guess I'm suggest to just install 64-bit packages and don't bother
pulling in any 32-bit packages until they're needed. What's wrong with
that?
Because like it or not, people run a lot of software that's not packaged
as an RPM. And so there's no good way for them to say "what 32bit
libraries do I maybe need here". A huge amount of the reason why x86_64
has succeeded where, eg, ppc or ia64 haven't is *BECAUSE* of this
compatibility. The fact that you can just use your 32bit apps without
having to think about it is a major benefit to the platform. And that's
a message that has been very strongly and loudly communicated by
non-technical users and customers who want their software to just work.
> > Btw, you didn't answer my question though- can you do
package selection
> > in kickstart based on what arch it is?
>
> I don't believe so.
Perhaps that's something it needs to do. We're going to end up seeing
size differences in ISO files for archs. For example x86 livecd may be
30MB smaller than ppc livecd; that space can and should be used for
something useful such as more themes, more promotional materials or
whatever.
When the kickstart inheritance lands, that provides an easy way of doing
this. I still don't think that it's something that you _want_. One of
the advantages of Linux has always been that you get a consistent
experience regardless of the architecture that you're on. The live CD
should be the same idea here.
Jeremy
11:05 p.m.
On Wed, 2007-03-07 at 13:47 -0500, Jeremy Katz wrote:
Because like it or not, people run a lot of software that's not
packaged
as an RPM. And so there's no good way for them to say "what 32bit
libraries do I maybe need here". A huge amount of the reason why x86_64
has succeeded where, eg, ppc or ia64 haven't is *BECAUSE* of this
compatibility. The fact that you can just use your 32bit apps without
having to think about it is a major benefit to the platform. And that's
a message that has been very strongly and loudly communicated by
non-technical users and customers who want their software to just work.
If I'm on a 64-bit system without any 32-bit packages, I'd expect our
package management software to pull in the 32-bit deps if I decide to
install a 32-bit app. Isn't that how Pirut works today anyway?
David
8 a.m.
On Thursday 08 March 2007 00:05:57 David Zeuthen wrote:
If I'm on a 64-bit system without any 32-bit packages, I'd
expect our
package management software to pull in the 32-bit deps if I decide to
install a 32-bit app. Isn't that how Pirut works today anyway?
Perhaps you missed the part about:
Because like it or not, people run a lot of software that's not
packaged
as an RPM.
--
Jesse Keating
Release Engineer: Fedora
8:06 a.m.
Jesse Keating wrote:
On Thursday 08 March 2007 00:05:57 David Zeuthen wrote:
> If I'm on a 64-bit system without any 32-bit packages, I'd expect our
> package management software to pull in the 32-bit deps if I decide to
> install a 32-bit app. Isn't that how Pirut works today anyway?
Perhaps you missed the part about:
> Because like it or not, people run a lot of software that's not packaged
> as an RPM.
This is not the group we should serving by default. We dont serve the
end users who dont use RPM packages very well anyway. From the number of
complaints we have got on this topic, I would think the default should
be to just install x86_64 packages.
Rahul
8:37 a.m.
On Thu, 2007-03-08 at 19:36 +0530, Rahul Sundaram wrote:
Jesse Keating wrote:
> On Thursday 08 March 2007 00:05:57 David Zeuthen wrote:
>> If I'm on a 64-bit system without any 32-bit packages, I'd expect our
>> package management software to pull in the 32-bit deps if I decide to
>> install a 32-bit app. Isn't that how Pirut works today anyway?
>
> Perhaps you missed the part about:
>
>> Because like it or not, people run a lot of software that's not packaged
>> as an RPM.
This is not the group we should serving by default. We dont serve the
end users who dont use RPM packages very well anyway. From the number of
complaints we have got on this topic, I would think the default should
be to just install x86_64 packages.
Funny. We used to do that. I got more complaints.
There's no way to win on this one. I'd far rather the downside be "use
space, but things work" than the alternative where people try to use
foo, see it not work and say "Fedora sucks, screw it, I'm going to run
something else".
Jeremy
8:42 a.m.
Le jeudi 08 mars 2007 à 09:37 -0500, Jeremy Katz a écrit :
There's no way to win on this one. I'd far rather the
downside be "use
space, but things work" than the alternative where people try to use
foo, see it not work and say "Fedora sucks, screw it, I'm going to run
something else".
Oh another post on ESR... =:-p
Tony
--
10:11 a.m.
On Thu, 2007-03-08 at 09:00 -0500, Jesse Keating wrote:
On Thursday 08 March 2007 00:05:57 David Zeuthen wrote:
> If I'm on a 64-bit system without any 32-bit packages, I'd expect our
> package management software to pull in the 32-bit deps if I decide to
> install a 32-bit app. Isn't that how Pirut works today anyway?
Perhaps you missed the part about:
> Because like it or not, people run a lot of software that's not packaged
> as an RPM.
I doubt people are going to install software on a live CD. Perhaps you
missed the point about that they will get the deps installed anyway.
David
10:24 a.m.
On Thursday 08 March 2007 11:11:28 David Zeuthen wrote:
> > Because like it or not, people run a lot of software
that's not
> > packaged as an RPM.
I doubt people are going to install software on a live CD. Perhaps you
missed the point about that they will get the deps installed anyway.
Why wouldn't they nfs mount some shared drive and run an app that is sitting
there? Or a game?
If the software they are using/installing isn't in rpm format, they aren't
going to just magically get the deps.
--
Jesse Keating
Release Engineer: Fedora
10:42 a.m.
On Thu, 2007-03-08 at 11:24 -0500, Jesse Keating wrote:
On Thursday 08 March 2007 11:11:28 David Zeuthen wrote:
> > > Because like it or not, people run a lot of software that's not
> > > packaged as an RPM.
>
> I doubt people are going to install software on a live CD. Perhaps you
> missed the point about that they will get the deps installed anyway.
Why wouldn't they nfs mount some shared drive and run an app that is sitting
there? Or a game?
If the software they are using/installing isn't in rpm format, they aren't
going to just magically get the deps.
Just to serve these two rather weird use cases [1] you're fine with not
making this fit on a 700MB. I don't think this is a good idea. Thanks.
David
[1] : for a live CD anyway
10:59 a.m.
On Thursday 08 March 2007 11:42:21 David Zeuthen wrote:
Just to serve these two rather weird use cases [1] you're fine
with not
making this fit on a 700MB. I don't think this is a good idea. Thanks.
I don't have a good answer. Either we cut out this capability of the x86_64
platform, and create a case where the installed from LiveCD differs pretty
dramatically from the installed from real media, or we try to find a way to
make it fit, or pass on multi-arch LiveCDs in general. Solving this for
ppc64 is not going to be any easier, you can't just say 'you only get ppc64
packages' as that is really stupid for that platform.
--
Jesse Keating
Release Engineer: Fedora
11:08 a.m.
On Thu, 2007-03-08 at 11:59 -0500, Jesse Keating wrote:
On Thursday 08 March 2007 11:42:21 David Zeuthen wrote:
> Just to serve these two rather weird use cases [1] you're fine with not
> making this fit on a 700MB. I don't think this is a good idea. Thanks.
I don't have a good answer. Either we cut out this capability of the x86_64
platform, and create a case where the installed from LiveCD differs pretty
dramatically from the installed from real media, or we try to find a way to
make it fit, or pass on multi-arch LiveCDs in general. Solving this for
ppc64 is not going to be any easier, you can't just say 'you only get ppc64
packages' as that is really stupid for that platform.
So I don't really think that the lack of secondary-arch rpms on the live
cd (no 32-bit packages for x86_64, (almost no) 64-bit packages on ppc64)
is going to create this horror picture where things are dramatically
different as long as our repos still contain the secondary-arch packages
and our tools, e.g. yum and pirut and whatever, is capable of pulling in
the deps. Besides, the live CD already differs from the installed set;
there's no OO.o to start with for instance.
David
11:15 a.m.
On Thursday 08 March 2007 12:08:16 David Zeuthen wrote:
So I don't really think that the lack of secondary-arch rpms on
the live
cd (no 32-bit packages for x86_64, (almost no) 64-bit packages on ppc64)
is going to create this horror picture where things are dramatically
different as long as our repos still contain the secondary-arch packages
and our tools, e.g. yum and pirut and whatever, is capable of pulling in
the deps. Besides, the live CD already differs from the installed set;
there's no OO.o to start with for instance.
It's not about the package count, it's about the capability. You're removing
the capability for an x86_64 live CD to run 32bit software. That is a
feature we are quite proud of for Fedora. We spent a lot of time and effort
to make it work a best we could, when other distributions decided to just
pass on it. Removing this functionality from something we'll want to be able
to use to show off our features seems like a bad decision to me. The damned
constraint of 700megs is what kills us time and time again, and it will only
get worse. The functionality of our LiveCD will only get worse over time if
we stick to CD size. Perhaps we do only DVD live images for multiarch
platforms. The tool set should still allow for creating a single arch x86_64
CD, but that isn't something I want to publish as any sort of official Fedora
release.
--
Jesse Keating
Release Engineer: Fedora
11:29 a.m.
On Thu, 2007-03-08 at 12:15 -0500, Jesse Keating wrote:
On Thursday 08 March 2007 12:08:16 David Zeuthen wrote:
> So I don't really think that the lack of secondary-arch rpms on the live
> cd (no 32-bit packages for x86_64, (almost no) 64-bit packages on ppc64)
> is going to create this horror picture where things are dramatically
> different as long as our repos still contain the secondary-arch packages
> and our tools, e.g. yum and pirut and whatever, is capable of pulling in
> the deps. Besides, the live CD already differs from the installed set;
> there's no OO.o to start with for instance.
It's not about the package count, it's about the capability. You're removing
the capability for an x86_64 live CD to run 32bit software. That is a
feature we are quite proud of for Fedora.
Sigh... Why didn't you just say so in the first place instead of coming
up with broken reasons like running software from NFS (on the livecd
even!) and the like? I still think it's really silly but, yeah,
sometimes we do inconvenience the user to show of features.
We spent a lot of time and effort
to make it work a best we could, when other distributions decided to just
pass on it. Removing this functionality from something we'll want to be able
to use to show off our features seems like a bad decision to me. The damned
constraint of 700megs is what kills us time and time again, and it will only
get worse.
We also include a lot of useless crap due to packaging bugs like
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229442
and also a ton of duplicate artwork etc. When I worked on OLPC we
managed to fix some of this, including silly dependencies like the X
server pulling in perl. I'm fearing it's slowly creeping in again:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230056
I guess keeping bloat to a minimum is not fashionable these days and to
some people "more packages == better product". Sad.
Here's a constructive idea: perhaps someone should investigate the price
difference on the cost of creating DVD media vs. CD media. To me it
sounds like you think it's zero. I haven't checked for a while though;
perhaps Greg knows as he is getting media prepared?
Then, there's also the bandwidth issues; the more we include on the
livecd (which will get installed), the more updates our users will have
to download and in some regions bandwidth is extremely scarce.
The functionality of our LiveCD will only get worse over time if
we stick to CD size. Perhaps we do only DVD live images for multiarch
platforms. The tool set should still allow for creating a single arch x86_64
CD, but that isn't something I want to publish as any sort of official Fedora
release.
Well, I can hear it's certainly not my call so I'll just be quiet.
David
3:20 p.m.
On Thursday 08 March 2007 12:29:23 David Zeuthen wrote:
Sigh... Why didn't you just say so in the first place instead of
coming
up with broken reasons like running software from NFS (on the livecd
even!) and the like? I still think it's really silly but, yeah,
sometimes we do inconvenience the user to show of features.
Probably because as the argument progressed I remembered some of why we do
this for the actual install in the first place. (:
> We spent a lot of time and effort
> to make it work a best we could, when other distributions decided to just
> pass on it. Removing this functionality from something we'll want to be
> able to use to show off our features seems like a bad decision to me.
> The damned constraint of 700megs is what kills us time and time again,
> and it will only get worse.
We also include a lot of useless crap due to packaging bugs like
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229442
Yeah, it is good to find these things now that we're putting our software back
into constrained areas, like a LiveCD and OLPC. More splitting is sometimes
good, but at the same time there is the cost of feature discoverability. I
installed <foo> and tried to do <bar> with it, but I couldn't so I gave up
on
<foo> not realizing that I had to install <foo>-<bar> in order to get
that
functionality. It's an ugly problem :/
and also a ton of duplicate artwork etc. When I worked on OLPC we
managed to fix some of this, including silly dependencies like the X
server pulling in perl. I'm fearing it's slowly creeping in again:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230056
Yes, proper packaging rules do expose some packaging issues like this. The
solution isn't to ignore the rules, it's to adjust the package so that they
follow the rules to promote proper packaging. We don't just make up these
rules because we think they're fun, there are problems and concerns around
most of these beyond just "consistency".
I guess keeping bloat to a minimum is not fashionable these days and
to
some people "more packages == better product". Sad.
Where are you seeing that? I think it is more "more package options == better
product" not more packages in the install or spin. More options, more
thoughts/discussion/experminitation on how to cut them up leads to better
experiences.
Here's a constructive idea: perhaps someone should investigate
the price
difference on the cost of creating DVD media vs. CD media. To me it
sounds like you think it's zero. I haven't checked for a while though;
perhaps Greg knows as he is getting media prepared?
Perhaps he does. Lets CC him and find out.
Then, there's also the bandwidth issues; the more we include on
the
livecd (which will get installed), the more updates our users will have
to download and in some regions bandwidth is extremely scarce.
Very true.
> The functionality of our LiveCD will only get worse over time
if
> we stick to CD size. Perhaps we do only DVD live images for multiarch
> platforms. The tool set should still allow for creating a single arch
> x86_64 CD, but that isn't something I want to publish as any sort of
> official Fedora release.
Well, I can hear it's certainly not my call so I'll just be quiet.
It's not my call alone either. Ultimately it is the Fedora Board's call if we
can't all come to an agreement.
--
Jesse Keating
Release Engineer: Fedora
3:23 p.m.
On Thu, 8 Mar 2007, Jesse Keating wrote:
> Here's a constructive idea: perhaps someone should
investigate the price
> difference on the cost of creating DVD media vs. CD media. To me it
> sounds like you think it's zero. I haven't checked for a while though;
> perhaps Greg knows as he is getting media prepared?
Perhaps he does. Lets CC him and find out.
Good thing I'm already on the list, as your efforts to CC: me at the wrong
address would have been a failure. :)
There is a slight difference in cost between CD and DVD production -- but
any difference will be well within budget. The issue will not be "which
will cost more to produce, a CD or a DVD?" but rather: "which is better
for our target audience, a CD or a DVD?"
>> The functionality of our LiveCD will only get worse over time
if we
>> stick to CD size. Perhaps we do only DVD live images for multiarch
>> platforms. The tool set should still allow for creating a single arch
>> x86_64 CD, but that isn't something I want to publish as any sort of
>> official Fedora release.
>
> Well, I can hear it's certainly not my call so I'll just be quiet.
It's not my call alone either. Ultimately it is the Fedora Board's call
if we can't all come to an agreement.
Can somebody recapitulate the heart of the argument in, oh, a paragraph?
--g
-------------------------------------------------------------
Greg DeKoenigsberg || Fedora Project || fedoraproject.org
Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors
-------------------------------------------------------------
3:43 p.m.
On Thursday 08 March 2007 16:23:28 Greg Dekoenigsberg wrote:
Can somebody recapitulate the heart of the argument in, oh, a
paragraph?
To multilib or not to multilib: that is the question:
Whether 'tis noble in the project to suffer
the same functionality of the regular install
upon the live CD
Or to take away features to fit on one CD
ok enough of that.
Basically if we do an x86_64 LiveCD the question is whether or not to do
multilib, that is enable being able to run 32bit code/apps on the LiveCD and
upon the system once a user has done an install from LiveCD. If we do
multilib, we get hurt some on space, and will probably have to do a LiveDVD
instead or drop a lot more packages.
David is of the opinion of sacrificing the feature of multilib to deliver an
x86_64 pure LiveCD that fits on a CD, while I'm of the opinion that we
shouldn't drop that feature especially as the regular install will in fact
install multilib stuff, while the install from LiveCD will not have any of
that in place.
I think there may be some other opinions, I know Jeremy seems to be in favor
of multilib, but he's about to be on vacation for a week+ so we may not see
his input.
--
Jesse Keating
Release Engineer: Fedora
2:03 p.m.
On Thu, 2007-03-08 at 16:43 -0500, Jesse Keating wrote:
On Thursday 08 March 2007 16:23:28 Greg Dekoenigsberg wrote:
> Can somebody recapitulate the heart of the argument in, oh, a paragraph?
To multilib or not to multilib: that is the question:
Whether 'tis noble in the project to suffer
the same functionality of the regular install
upon the live CD
Or to take away features to fit on one CD
ok enough of that.
Basically if we do an x86_64 LiveCD the question is whether or not to do
multilib, that is enable being able to run 32bit code/apps on the LiveCD and
upon the system once a user has done an install from LiveCD. If we do
multilib, we get hurt some on space, and will probably have to do a LiveDVD
instead or drop a lot more packages.
David is of the opinion of sacrificing the feature of multilib to deliver an
x86_64 pure LiveCD that fits on a CD, while I'm of the opinion that we
shouldn't drop that feature especially as the regular install will in fact
install multilib stuff, while the install from LiveCD will not have any of
that in place.
I think there may be some other opinions, I know Jeremy seems to be in favor
of multilib, but he's about to be on vacation for a week+ so we may not see
his input.
Yeah, for x86_64 (and probably any attempt to satisfy ppc64 users[1]), I
really think that given the target of users, going over the size of a CD
and requiring the live image to be on a DVD isn't a big deal. Our
download numbers for x86_64 clearly point to the vast majority being
DVD. This _doesn't_ mean that we fill the DVD and require people to
download 3 gigs or whatever... but if you have to download (say for the
sake of argument... I'll try to do a spin later today or tomorrow to get
real numbers) 850 megs on x86_64 and get the increased capability, that
really feels like a win. Especially as if you have an x86_64, you're
far more likely to have a DVD drive (+burner) as well as more bandwidth
just based on the pure economics. And if not, the x86 live CD is there
and will run on your hardware also, you just have a different tradeoff
of which bits of functionality you use.
Jeremy
[1] I'd argue at this point that trying to do a live CD supporting ppc64
may be silly for F7. The lack of anyone stepping up with patches for
ppc may make any of it a moot point. :-)
3:25 p.m.
Jesse Keating (jkeating(a)redhat.com) said:
Why wouldn't they nfs mount some shared drive and run an app that
is sitting
there? Or a game?
If the software they are using/installing isn't in rpm format, they aren't
going to just magically get the deps.
For a *live CD* I believe this is less of a concern, as, while the
fact that you can install software is neat, it's not the main selling
point.
Now, if you start thinking about a live USB stick, this changes. Of
course, that doesn't have the same space constraints.
Bill
3:52 p.m.
On Thursday 08 March 2007 16:25:25 Bill Nottingham wrote:
For a *live CD* I believe this is less of a concern, as, while the
fact that you can install software is neat, it's not the main selling
point.
Now, if you start thinking about a live USB stick, this changes. Of
course, that doesn't have the same space constraints.
LiveCD matters as one can install to the system from the LiveCD, and they'll
be left with an install that cannot do multilib without installing a bunch
more stuff. If it weren't for the fact that the LiveCD is installable (and
by the looks of our download numbers many people may be taking that route) I
probably wouldn't have that much objection.
--
Jesse Keating
Release Engineer: Fedora
11:10 a.m.
On Tue, 2007-03-06 at 13:26 -0500, David Zeuthen wrote:
On Tue, 2007-03-06 at 11:27 -0500, Jeremy Katz wrote:
> On Mon, 2007-03-05 at 22:07 -0500, David Zeuthen wrote:
> > Sorry for being slow in reviewing patches; most of my time past two
> > month been spent traveling and working on other features on Fedora 7.
> > Enough with bad excuses. Anyway, looks like Jeremy and Bill been kicking
> > ass writing patches so I've merged them all into master.
>
> Cool, sounds good.
>
> > Btw, Jeremy, where can I find a kickstart file?
>
> I sent one with the initial kickstart patch. My current one doesn't
> quite fit on a CD as I try to make it have roughly the same package set
> as the default distro install does.
I tried this last night but livecd-creator fails without useful error
messages.. and cleanup don't work so I'm left with /dev/loop0 which is
mounted and I have to clean up by hand. Not to sound like a whiner
(though I probably am) but please fix look into this and make sure that
HEAD don't contain such errors in the future. HEAD should always be
working.
(FWIW, I think this is because yum is throwing exceptions left and right
when adding groups and packages.)
It's working fine for me here with a fresh clone... do you have more
information on said exceptions? Attached patch should make it so that
you get a traceback instead of just a printout of "something bad
happened". Since that should help a lot when people actually have
problems.
Jeremy
PS Will get to the rest of the mails after lunch
10:57 p.m.
On Wed, 2007-03-07 at 12:10 -0500, Jeremy Katz wrote:
It's working fine for me here with a fresh clone... do you have
more
information on said exceptions? Attached patch should make it so that
you get a traceback instead of just a printout of "something bad
happened". Since that should help a lot when people actually have
problems.
I've committed this, thanks. I'm still getting
ERROR during installation...
Traceback (most recent call last):
File "./livecd-creator", line 785, in main
if not target.installPackages(packages, epackages, groups):
File "./livecd-creator", line 466, in installPackages
self.ayum.selectGroup(grp, inc)
File "./livecd-creator", line 218, in selectGroup
yum.YumBase.selectGroup(self, grp)
File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 1417, in
selectGroup
raise Errors.GroupsError, "No Group named %s exists" % grpid
GroupsError: No Group named core exists
which at least is somewhat useful. Perhaps this is because I'm using a
local RPM repo that I've ran createrepo on myself? For the record, I'm
able to get a bit further if I choose to only install the bash and the
kernel package.
David
8:01 a.m.
On Wednesday 07 March 2007 23:57:38 David Zeuthen wrote:
which at least is somewhat useful. Perhaps this is because I'm
using a
local RPM repo that I've ran createrepo on myself? For the record, I'm
able to get a bit further if I choose to only install the bash and the
kernel package.
If you're only using your own repo, it needs to have group information. You
need to pass createrepo a comps file at createrepo time. See the -g option
to createrepo.
--
Jesse Keating
Release Engineer: Fedora
10:10 a.m.
On Thu, 2007-03-08 at 09:01 -0500, Jesse Keating wrote:
On Wednesday 07 March 2007 23:57:38 David Zeuthen wrote:
> which at least is somewhat useful. Perhaps this is because I'm using a
> local RPM repo that I've ran createrepo on myself? For the record, I'm
> able to get a bit further if I choose to only install the bash and the
> kernel package.
If you're only using your own repo, it needs to have group information. You
need to pass createrepo a comps file at createrepo time. See the -g option
to createrepo.
Interesting. And where do I obtain the comps file?
David
10:22 a.m.
On Thursday 08 March 2007 11:10:14 David Zeuthen wrote:
Interesting. And where do I obtain the comps file?
There is one in the upstream repos, in repodata/comps.xml usually. Check the
repomd.xml from your upstream repos. Alternatively you can grab it from our
internal CVS :devel/comps
A comps file is one of the things necessary for a pungi spin.
--
Jesse Keating
Release Engineer: Fedora
6257
days inactive
6270
days old
livecd@lists.fedoraproject.org
44 comments
8 participants
participants (8)
-
Bill Nottingham -
David Zeuthen -
Greg DeKoenigsberg -
Jane Dogalt -
Jeremy Katz -
Jesse Keating -
Rahul Sundaram -
tony