I have been following the various discussions of reducing the CD count and have the following comments:
1. I agree with those who want to expand the FC4 set to 5 CD images and then put the big reduction effort into the FC5 timeframe when anaconda can/should be able to handle multiple "respositories" (and, homefully, pup also).
2. Lets say something major which a lot of users will want is move out of the "core core" and into a secondary "repository" which will still be fully maintained by Red Hat employees. No flaming intended, but lets say this is kde and all kde associated applications. Now that would be a big chunk but it would also be something a lot of users would want. What is the current thinking about how this "secondary repository" will be available to the user? Furthermore, this must be done in such a manner that it is obvious that Red Hat is NOT slighting the packages involved.
3. Can someone point me to the mailing list where the discussions are being held about this future multiple repository?
4. I am a little concerned about the discussion of multiple repositories and getting the CD count does to below four. What I am reading into the "multiple repository" discussions so far is that there would be a small number of CD images but then the rest of the packages would be pulled in off the Internet. While this should work in most cases, there does exist a need to have stand-alone systems or small networks of systems which have no connectivity to the Internet. Currently, with everything on CD or DVD images, things work for these stand-alone systems. True, getting updates to these systems is a bit more work requiring downloading, burning to DVD or CD and then moving to the unconnected systems but it does work. If large pieces of the "core" is only available via the Internet, then this can cause a great deal of additional effort.
5. There was some mention of RHEL having "extra" packages which are not part of the RHEL on CDs. How does RHEL handle the extra packages for stand-alone systems?
6. Currently, I pick and choose a small number of extra packages from Fedora Extras and other rpm repositories. If large number of packages which a lot of individuals may want are moved into secondary repositories, how will things be handled? Will there be CD and/or DVD images available of these repositories?
7. Currently, I do everything installs of Fedora Core for many installations simply because it is easier than adding a lot of stuff manually ... even if this does include a lot of packages that I have no need to install ... it is just simpler to include them. However, doing "everything everything" installs which would include packages from a Core, Extended Core, Extras, and other repositories, does not sound like it would work. There must be a better way.
My view of how installation should work is that the basic installation should be just that ... basic. Then, during firstboot (and available at later times too), you run something like pup (I hope this is the intent) to add additional packages and groupings of packages ... this does need to have the ability to select package installation/removal on an individual package basis. Large groupings of packages (e.g., KDE) should be available as CD or DVD images.
Comments?
On Thu, 24 Feb 2005, Gene C. wrote:
- I agree with those who want to expand the FC4 set to 5 CD images and
then put the big reduction effort into the FC5 timeframe when anaconda can/should be able to handle multiple "respositories" (and, homefully, pup also).
Something that needs to be mentioned - it was decided that it was better to go to 5 CDs for now than to kick eclipse and the Java stuff out. However, there is plenty of other stuff that can be moved to Extras right now, and as you've seen that has already been happening (maintainers still wanted for some of that stuff!).
-- Elliot
Elliot Lee wrote :
On Thu, 24 Feb 2005, Gene C. wrote:
- I agree with those who want to expand the FC4 set to 5 CD images and
then put the big reduction effort into the FC5 timeframe when anaconda can/should be able to handle multiple "respositories" (and, homefully, pup also).
Something that needs to be mentioned - it was decided that it was better to go to 5 CDs for now than to kick eclipse and the Java stuff out. However, there is plenty of other stuff that can be moved to Extras right now, and as you've seen that has already been happening (maintainers still wanted for some of that stuff!).
For clearly obsolete stuff (input methods...) I really don't mind packages being removed, but I see at least 3 issues with what got dropped :
- Exim was removed... it's tiny, and was in FC3, so that's probably a bad idea. - Xfce was removed... this leaves FC with no lightweight desktop manager, and it was in FC3 AFAIR, so again... - Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off".
I don't have strong feelings about sylpheed, abiword/gnumeric and most (if not all) of the others, but for these 3 points, I definitely do.
Matthias
On Thu, 24 Feb 2005, Matthias Saou wrote:
- Exim was removed... it's tiny, and was in FC3, so that's probably a bad idea.
- Xfce was removed... this leaves FC with no lightweight desktop manager, and it was in FC3 AFAIR, so again...
Packages aren't being removed because they're not useful. Nobody is disputing that exim is useful to people or that xfce is a good thing for some users.
The question is not whether it's useful, it's whether it's an essential to the goal of Fedora Core as the "Core", as a general purpose OS.
The package removals so far are just a start. We're not there yet. There's still plenty more to move from Core to Extras (or just drop altogether). The advantage for you is that moving things from Core to Extras gives you more control over the package. It becomes a lot easier for you to contribute more directly as a packager.
The disadvantage is that people somehow see moving from Core to Extras as an insult against their package, which couldn't be farther from the intention.
- Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off".
It can be showed off without being included in Core.
-- Elliot
On Thu, 2005-02-24 at 12:21 -0500, Elliot Lee wrote:
The disadvantage is that people somehow see moving from Core to Extras as an insult against their package, which couldn't be farther from the intention.
If we've given up the goal of cutting the i386 install down to 4CDs, we really ought to wait till anaconda can handle Extras properly in FC5 before we go dumping packages there. For upgrades to FC4, if the package is in Extras it might as well not exist.
- Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off".
It can be showed off without being included in Core.
Not until FC5, it can't.
David Woodhouse wrote :
On Thu, 2005-02-24 at 12:21 -0500, Elliot Lee wrote:
The disadvantage is that people somehow see moving from Core to Extras
as
an insult against their package, which couldn't be farther from the intention.
If we've given up the goal of cutting the i386 install down to 4CDs, we really ought to wait till anaconda can handle Extras properly in FC5 before we go dumping packages there. For upgrades to FC4, if the package is in Extras it might as well not exist.
- Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off".
It can be showed off without being included in Core.
Not until FC5, it can't.
My thoughts exactly. The cutting off is a bit too premature IMHO, and my concerns aren't related to certain software being perceived as becoming "2nd class", but more to the fact that we won't be able to trivially get this software on FC4 systems (I'm not thinking of my own computers but those like my dad's, sitting behind a modem connection with only s-c-p to manage installed software).
Given how we are headed for FC4, things _can't_ be showed off easily without being included in Core, or at least that's the impression I have, and will still have until anaconda evolves or that we're sure to have rebuilt Extras on the day a new FC is released...
Alright... </rant> ;-)
Matthias
On Feb 24, 2005, Elliot Lee sopwith@redhat.com wrote:
The question is not whether it's useful, it's whether it's an essential to the goal of Fedora Core as the "Core", as a general purpose OS.
The package removals so far are just a start. We're not there yet.
Yup. We're not there yet. Since the insanity of taking packages out just because we had a 4-CD limit is gone, let's bring the useful packages back into core until we can offer users a *reasonable* solution to get those packages onto their systems. Extras as it stands isn't such a solution.
The disadvantage is that people somehow see moving from Core to Extras as an insult against their package, which couldn't be farther from the intention.
Pushing them anywhere before anaconda can support installing them is equivalent to removing them from the distro. Sure, you could still pick it up from elsewhere or build it yourself. Which is exactly what removing a package from the distro would accomplish.
On Thu, Feb 24, 2005 at 12:21:26PM -0500, Elliot Lee wrote:
- Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off".
It can be showed off without being included in Core.
I can no longer credibly work on fixing 3D bug reports. This *is* a problem
On Tue, 2005-03-01 at 08:46 -0500, Alan Cox wrote:
On Thu, Feb 24, 2005 at 12:21:26PM -0500, Elliot Lee wrote:
- Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off".
It can be showed off without being included in Core.
I can no longer credibly work on fixing 3D bug reports. This *is* a problem
So, just to make sure I understand, yum doesn't work for you?
You can't run: yum install bzflag2 tuxracer ?
-sv
seth vidal wrote:
I can no longer credibly work on fixing 3D bug reports. This *is* a problem
So, just to make sure I understand, yum doesn't work for you?
I think Alan was meaning more from a political standpoint. I suspect that Red Hat staff have more justification for fixing things in Core than Extras.
Carwyn
I think Alan was meaning more from a political standpoint. I suspect that Red Hat staff have more justification for fixing things in Core than Extras.
I don't think I understand how this is political. We're talking about a single command post-install. He was talking about debugging, I don't think it's CRAZY that a developer have to run a single command in order to debug something.
bzflag and tuxracer were not in the normal install in core, iirc. So why is it harder to install them now than before?
is it b/c they're in a separate repo? But that repo will be on by default for fc4, so how is that harder for the end user or developer?
-sv
On Tuesday 01 March 2005 09:05, seth vidal wrote:
I think Alan was meaning more from a political standpoint. I suspect that Red Hat staff have more justification for fixing things in Core than Extras.
I don't think I understand how this is political. We're talking about a single command post-install. He was talking about debugging, I don't think it's CRAZY that a developer have to run a single command in order to debug something.
bzflag and tuxracer were not in the normal install in core, iirc. So why is it harder to install them now than before?
both bzflag & tuxracer are in the default "personal desktop" install in fedora core 3.
is it b/c they're in a separate repo? But that repo will be on by default for fc4, so how is that harder for the end user or developer?
How does the end user know that these exist and that they are games?
On Tuesday 01 March 2005 10:23, seth vidal wrote:
is it b/c they're in a separate repo? But that repo will be on by default for fc4, so how is that harder for the end user or developer?
How does the end user know that these exist and that they are games?
yum search games
returns all of them.
heh, learn something new every day.
seth vidal wrote:
I don't think I understand how this is political.
It's "political" in the sense that it depends more on RH policies than common sense in some respects :-)
If RH give core a higher policital (business case) priority then bug priority for stuff that's in extras may well be lower.
It depends if Alan meant "credibly" in the justification of work sense or the testing coverage sense (maybe both).
Carwyn
-- School of Informatics University of Edinburgh
On Tue, Mar 01, 2005 at 02:56:33PM +0000, Carwyn Edwards wrote:
If RH give core a higher policital (business case) priority then bug priority for stuff that's in extras may well be lower.
We have internal priorities but they are based on common sense things you'd expect. If I have a "fix right now" IDE corruption problem and a bzflag bug then the bzflag bug will not be the priority bug. Not that bzflag has bugs 8)
Alan
We have internal priorities but they are based on common sense things you'd expect. If I have a "fix right now" IDE corruption problem and a bzflag bug then the bzflag bug will not be the priority bug. Not that bzflag has bugs
No, BZFlag has features, some of the new ones are better graphics and wings. Any chance bzflag2 will get built for fc3?
Richard June wrote :
We have internal priorities but they are based on common sense things
you'd
expect. If I have a "fix right now" IDE corruption problem and a bzflag
bug
then the bzflag bug will not be the priority bug. Not that bzflag has
bugs
No, BZFlag has features, some of the new ones are better graphics and
wings.
Any chance bzflag2 will get built for fc3?
Well, you can get it from here if you want : http://heidelberg.freshrpms.net/
Matthias
On Tuesday 01 March 2005 17:13, Matthias Saou wrote:
Richard June wrote :
We have internal priorities but they are based on common sense things
you'd
expect. If I have a "fix right now" IDE corruption problem and a bzflag
bug
then the bzflag bug will not be the priority bug. Not that bzflag has
bugs
No, BZFlag has features, some of the new ones are better graphics and
wings.
Any chance bzflag2 will get built for fc3?
Well, you can get it from here if you want : http://heidelberg.freshrpms.net/
I rebuilt the package myself, I was curious to see if it would become an fc3 update
Richard June wrote :
Any chance bzflag2 will get built for fc3?
Well, you can get it from here if you want : http://heidelberg.freshrpms.net/
I rebuilt the package myself, I was curious to see if it would become an
fc3
update
I really doubt it, as BZFlag 2 network play isn't compatible with BZFlag 1.
Matthias
since most of the servers have already moved to bzflag2, it makes sense to update it.
On Tue, 2005-03-01 at 10:27 -0500, Alan Cox wrote:
then the bzflag bug will not be the priority bug. Not that bzflag has bugs 8)
No *reproducible* bugs ; )
On Tue, Mar 01, 2005 at 01:56:04PM +0000, Carwyn Edwards wrote:
I can no longer credibly work on fixing 3D bug reports. This *is* a problem
So, just to make sure I understand, yum doesn't work for you?
I think Alan was meaning more from a political standpoint. I suspect that Red Hat staff have more justification for fixing things in Core than Extras.
Its a lot harder to deal with 3D bugs unless you know the precise binary and environment the user has to reproduce it. Now if Extras goes in out of the box then it may work for most users (except .de of course)
Alan
On Tue, 2005-03-01 at 10:19 -0500, Alan Cox wrote:
On Tue, Mar 01, 2005 at 01:56:04PM +0000, Carwyn Edwards wrote:
I can no longer credibly work on fixing 3D bug reports. This *is* a problem
So, just to make sure I understand, yum doesn't work for you?
I think Alan was meaning more from a political standpoint. I suspect that Red Hat staff have more justification for fixing things in Core than Extras.
Its a lot harder to deal with 3D bugs unless you know the precise binary and environment the user has to reproduce it. Now if Extras goes in out of the box then it may work for most users (except .de of course)
why won't it work in .de?
-sv
On Tue, Mar 01, 2005 at 10:26:06AM -0500, seth vidal wrote:
then it may work for most users (except .de of course)
why won't it work in .de?
Because the game is not part of a basic OS product and has not been through video game approval.
See: http://www.germanlawjournal.com/current_issue.php?id=279
Actually reading the material about this again it may be a good reason for keeping bzflag in extras.
Alan
On Tue, 2005-03-01 at 10:33 -0500, Alan Cox wrote:
On Tue, Mar 01, 2005 at 10:26:06AM -0500, seth vidal wrote:
then it may work for most users (except .de of course)
why won't it work in .de?
Because the game is not part of a basic OS product and has not been through video game approval.
See: http://www.germanlawjournal.com/current_issue.php?id=279
Actually reading the material about this again it may be a good reason for keeping bzflag in extras.
so is germany not in the free world anymore either?
heh
-sv
On Tue, Mar 01, 2005 at 10:38:43AM -0500, seth vidal wrote:
Actually reading the material about this again it may be a good reason for keeping bzflag in extras.
so is germany not in the free world anymore either?
I don't know enough about what the German people think about the issue to even speculate. I'm not sure bzflag exactly glorifies war but I do need to find more out about that.
[PS Farenheit 451 is a great book]
Alan
Alan Cox wrote:
On Tue, Mar 01, 2005 at 10:38:43AM -0500, seth vidal wrote:
Actually reading the material about this again it may be a good reason for keeping bzflag in extras.
so is germany not in the free world anymore either?
I don't know enough about what the German people think about the issue to even speculate. I'm not sure bzflag exactly glorifies war but I do need to find more out about that.
As a home grown German (although possibly "polluted" by US propaganda :)) i think i can honestly say that at least i think we're still part of the free world ;)
If that's true is written in another book (see below), see also 1984 or Animal Farm (which are great books, too).
And despite possibly bzflag glorifying war it's still a damn fun game to play and it kept me up loads of nights way back when i was still at the University and sleep an uncessary burden. :)
[PS Farenheit 451 is a great book]
Never read it, i always intended to read it, buying it from Amazon NOW. :)
Read ya, Phil
[PS Farenheit 451 is a great book]
Never read it, i always intended to read it, buying it from Amazon NOW. :)
Read ya, Phil
plot summary: the gov't burns books and hunts down readers. People turn into drones watching tv. Some folks memorize books to carry on their stories. Moral: Book burning, bad. Reading, good.
-sv
On Tue, Mar 01, 2005 at 10:49:10AM -0500, seth vidal wrote:
plot summary: the gov't burns books and hunts down readers. People turn into drones watching tv. Some folks memorize books to carry on their stories. Moral: Book burning, bad. Reading, good.
Also, "having libraries on CD would be handy".
seth vidal wrote:
[PS Farenheit 451 is a great book]
Never read it, i always intended to read it, buying it from Amazon NOW. :)
Read ya, Phil
plot summary: the gov't burns books and hunts down readers. People turn into drones watching tv. Some folks memorize books to carry on their stories. Moral: Book burning, bad. Reading, good.
Good summary. And see, thats why i'm going to buy and read the book. And maybe later burn it, just to prove the point (whichever needs proving ;)) and see wether i feel good or bad about it aferwards to so i can decide wether i'm more prone to be a government official or a freedom of speach type of guy. Oh. Wait. I forgot, it's only a book and fiction... ;)
Read ya, Phil
seth vidal wrote:
On Tue, 2005-03-01 at 10:33 -0500, Alan Cox wrote:
Because the game is not part of a basic OS product and has not been through video game approval.
See: http://www.germanlawjournal.com/current_issue.php?id=279
so is germany not in the free world anymore either?
I sometimes do get that feeling, yes.
It's especially nice for those of us over 18 who are getting denied such things >:(
Ralph
Hi.
Alan Cox alan@redhat.com wrote:
Actually reading the material about this again it may be a good reason for keeping bzflag in extras.
Well, SuSE ships bzflag, also, and I do not remember seeing a sticker (since SuSE ships actual boxes contrary to Fedora) claiming that the product is unsuitable for persons aged below 18 (which would be the case if the game is not rated, which it obviously is not). Maybe a chat with the SuSE peole would clear that one up.
On Tue, 1 Mar 2005, Ralf Ertzinger wrote:
Alan Cox alan@redhat.com wrote:
Actually reading the material about this again it may be a good reason for keeping bzflag in extras.
Well, SuSE ships bzflag, also, and I do not remember seeing a sticker (since SuSE ships actual boxes contrary to Fedora) claiming that the product is unsuitable for persons aged below 18 (which would be the case if the game is not rated, which it obviously is not). Maybe a chat with the SuSE peole would clear that one up.
Resulting in Novell removing it from their distribution too ? :)
j/k
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi.
Dag Wieers dag@wieers.com wrote:
Resulting in Novell removing it from their distribution too ? :)
The regulation (which I personally consider a good thing, in contrast to the situation beforehand) covers _every_ game. Even solitaire. So as long as there is a single game in the distribution which is not covered by the USK, the distribution can not be sold to minors. In theory.
This is obviously bogus, and one of the situations in which the regulation breaks. Maybe someone else realized that, too, which is the reason why SuSE is still available for everyone to buy.
On Tue, 2005-03-01 at 10:19 -0500, Alan Cox wrote:
Its a lot harder to deal with 3D bugs unless you know the precise binary and environment the user has to reproduce it. Now if Extras goes in out of the box then it may work for most users (except .de of course)
Given the amount of 3rd party repo use that most end users have now anyway, expecting a precise binary and environment is rather tough to begin with.
However, Fedora Extras will be built on a maintained build server so that the binary Joe gets is the same binary you can get as well. As for environment, again, most end-users are pulling SOME 3rd party packages from SOMEwhere now anyway. Making it easier for YOU to match their environment by having them all in Extras, now isn't that a BONUS?
On Tue, 1 Mar 2005 10:19:24 -0500, Alan Cox alan@redhat.com wrote:
Its a lot harder to deal with 3D bugs unless you know the precise binary and environment the user has to reproduce it. Now if Extras goes in out of the box then it may work for most users (except .de of course)
from everything ive seen the intent is to have extras enabled by default in all repository aware tools that ship in core, yum,up2date and pup (when its ready). It should be just as easy to verify that a package is from extras as it is from core, when trying to compare your system to a user's system. It's not like it was safe to assume users weren't installing 3rd party versions of the games before... its the same verification step.. its just from a different repo at download.fedora.redhat.com Is there something specific about how Extras are built that makes debugging harder for you?
-jef
seth vidal writes:
So, just to make sure I understand, yum doesn't work for you?
You can't run: yum install bzflag2 tuxracer ?
Perhaps he's referring to the fact that he can no longer rely on an end user reporting a bug having a 3D application present with which to test any fixes. Remember, Extras will simply be unavailable to some people.
Tet
On Tue, 2005-03-01 at 13:58 +0000, Tet wrote:
seth vidal writes:
So, just to make sure I understand, yum doesn't work for you?
You can't run: yum install bzflag2 tuxracer ?
Perhaps he's referring to the fact that he can no longer rely on an end user reporting a bug having a 3D application present with which to test any fixes. Remember, Extras will simply be unavailable to some people.
1. so a user can report a bug (presumably by bugzilla, on the internet) but can't download bzflag or tuxracer? How is that unavailable?
2. also what about gl-gears or whatever it's called - it comes with x server, I thought, can't that be used as a tester?
-sv
On Mar 1, 2005, seth vidal skvidal@phy.duke.edu wrote:
- so a user can report a bug (presumably by bugzilla, on the internet)
but can't download bzflag or tuxracer? How is that unavailable?
How about: internet access only from work, monitored downloads, no CD burning permitted, small amount of web browsing tolerated?
On 01 Mar 2005 18:53:45 -0300, Alexandre Oliva aoliva@redhat.com wrote:
How about: internet access only from work, monitored downloads, no CD burning permitted, small amount of web browsing tolerated?
How does that system get any update packages at all?
-jef
On Mar 1, 2005, Jeff Spaleta jspaleta@gmail.com wrote:
On 01 Mar 2005 18:53:45 -0300, Alexandre Oliva aoliva@redhat.com wrote:
How about: internet access only from work, monitored downloads, no CD burning permitted, small amount of web browsing tolerated?
How does that system get any update packages at all?
Odds are it doesn't need them, since it's not connected.
On 02 Mar 2005 13:39:25 -0300, Alexandre Oliva aoliva@redhat.com wrote:
Odds are it doesn't need them, since it's not connected.
oh please... there are all sorts of updates that have come out that have had a direct impact on end-user facing elements to fix some annoying issues. Its not ALL about security fixes. There have been 'needed' functionality fixes. Even non-networked people who do updates of fc3 are going to notice a marked difference in some aspects of non-networked elements.. because of bug fixes. One man's unneeded update is another man's critical feature bugfix.
This whole line of argument that you are trying to make is errenous in the context of the original discussion about effective 3d testing. How can you do effective do 3d testing/troubleshooting if you can't eat the updates that are spun up to confirm the problem has been fixed on your hardware? Confirming the fix is sort of important.. and if you can't get the updates.. how do you confirm the fix?
The issue of trying to cram everything into the release isos is a completely red herring issue. If you want to work on the more important issue of how to build reliable mechanisms on how to get updates into the hands of system admins in network-poor environments that would be far more valuable in the long run.
-jef
On Mar 2, 2005, Jeff Spaleta jspaleta@gmail.com wrote:
Even non-networked people who do updates of fc3 are going to notice a marked difference in some aspects of non-networked elements.. because of bug fixes. One man's unneeded update is another man's critical feature bugfix.
Sure. If it's critical, and the person learns about the fix, I'm sure she'll find a way to get the update somehow.
The issue of trying to cram everything into the release isos is a completely red herring issue. If you want to work on the more important issue of how to build reliable mechanisms on how to get updates into the hands of system admins in network-poor environments that would be far more valuable in the long run.
Agreed. Way to go for FC5. If we could add support for picking updates from ISOs for FC5, we could even roll weekly-or-so ISO updates. Or just let the installer take CDs containing updates and figure out that, instead of installing something from core, it'd be better off installing the newer corresponding package from the updates CD.
On Wednesday 02 March 2005 11:39, Alexandre Oliva wrote:
On Mar 1, 2005, Jeff Spaleta jspaleta@gmail.com wrote:
On 01 Mar 2005 18:53:45 -0300, Alexandre Oliva aoliva@redhat.com wrote:
How about: internet access only from work, monitored downloads, no CD burning permitted, small amount of web browsing tolerated?
How does that system get any update packages at all?
Odds are it doesn't need them, since it's not connected.
While security updates may not have the same level of concern for unconnected systems, bugfixes are. With Fedora Core having a much higher number of updates issued than Red Hat Linux had, updating unconnected systems or network of systems is an issue with network-only updating.
As I see it there are two issues:
1. Will the updating program be able to pull updates from a CD or DVD with updated packages on it? If the current up2date has this capability, I have not been able to figure out how to make it work.
2. Will the master repositories be organized in such a manner as to "make it easy" to mirror updates. Yes, I know there will be official mirror sites but will I be able to easily get all the updates and then "move them" to some media for updating stand-alone systems or networks of systems.
My experience is that I have fewer problems if I keep up-to-date than if I just apply fixes when a problem occurs.
As I see it there are two issues:
- Will the updating program be able to pull updates from a CD or DVD
with updated packages on it? If the current up2date has this capability, I have not been able to figure out how to make it work.
This is pretty trivial to do with a small script that calls yum in a temp root and tells it to look at on-cd repodata.
Regards,
On Mar 3, 2005, "Nicolas Mailhot" nicolas.mailhot@laposte.net wrote:
This is pretty trivial to do with a small script that calls yum in a temp root and tells it to look at on-cd repodata.
Only if everything fits in a single medium. Since FE is quickly approaching the size of a 4.7GB DVD, what are the odds?
Le jeudi 03 mars 2005 à 15:01 -0300, Alexandre Oliva a écrit :
On Mar 3, 2005, "Nicolas Mailhot" nicolas.mailhot@laposte.net wrote:
This is pretty trivial to do with a small script that calls yum in a temp root and tells it to look at on-cd repodata.
Only if everything fits in a single medium. Since FE is quickly approaching the size of a 4.7GB DVD, what are the odds?
Surely FE is not so interlinked it should be possible to do independent update disks, right ?
Oh wait - I can see the problem if the updated part is a core package that caused 3/4th of FE to be rebuilt;(
Regards,
All this talk and not much action on the reduction in CD count.
I did some poking and proding of FC3 to see what we could get it down to. I discovered that base had a bad dependancy issue that cuased much more to be pulled into a base install than was necessary becase kdebindings was claiming ownership of /usr/lib/python2.3. Once I started using base+updates everything sorted itself out nicely.
Basicly I require 115mb of RPM's ( decompressed ~250mb in about 45 seconds ) in order to bootstrap a system up to the point where yum becomes usable. I then copy resolv.conf and chroot into the system. I can then run yum install [package] without problem. It turned out to be much easier than I expected and I'm thinking of continuing to use this process moving forward to build a simple yum based net install system in house. I figure I can modify the rescue cd to accomplish this task, possibly having enough room to also add a basic gnome install.
I think some of the scripts were failing because of some undeclared dependancies on files that need to be created by an installer, specifically /etc/fstab, so if someone has documentation on bootstrapping a Fedora based system that would be helpful.
Cheers, Eric Warnke System Administrator - Research IT SUNY at Albany
Eric Warnke wrote:
All this talk and not much action on the reduction in CD count.
I did some poking and proding of FC3 to see what we could get it down to. I discovered that base had a bad dependancy issue that cuased much more to be pulled into a base install than was necessary becase kdebindings was claiming ownership of /usr/lib/python2.3. Once I started using base+updates everything sorted itself out nicely.
Basicly I require 115mb of RPM's ( decompressed ~250mb in about 45 seconds ) in order to bootstrap a system up to the point where yum becomes usable. I then copy resolv.conf and chroot into the system. I can then run yum install [package] without problem. It turned out to be much easier than I expected and I'm thinking of continuing to use this process moving forward to build a simple yum based net install system in house. I figure I can modify the rescue cd to accomplish this task, possibly having enough room to also add a basic gnome install.
I think some of the scripts were failing because of some undeclared dependancies on files that need to be created by an installer, specifically /etc/fstab, so if someone has documentation on bootstrapping a Fedora based system that would be helpful.
I made an installable fc3 version down to 95 megs of RPMs for a total ISO size of 288M (*.img are bigger than needed and could be reduced too).
Peek here: ftp://ftp.blagblagblag.org/pub/BLAG/contrib/minifc3/
-Jeff
Hi.
Alexandre Oliva aoliva@redhat.com wrote:
How about: internet access only from work, monitored downloads, no CD burning permitted, small amount of web browsing tolerated?
Given the recent developments on this list these people are simply not the target group of Fedora. Pity for them.
On Tue, 2005-03-01 at 22:58 +0100, Ralf Ertzinger wrote:
Hi.
Alexandre Oliva aoliva@redhat.com wrote:
How about: internet access only from work, monitored downloads, no CD burning permitted, small amount of web browsing tolerated?
Given the recent developments on this list these people are simply not the target group of Fedora. Pity for them.
actually, no, in that situation the user is just going to have to ask wherever he/she got the fedora core cds from to burn them an iso of some pkgs from extras.
-sv
On Tue, 2005-03-01 at 18:53 -0300, Alexandre Oliva wrote:
On Mar 1, 2005, seth vidal skvidal@phy.duke.edu wrote:
- so a user can report a bug (presumably by bugzilla, on the internet)
but can't download bzflag or tuxracer? How is that unavailable?
How about: internet access only from work, monitored downloads, no CD burning permitted, small amount of web browsing tolerated?
so how did the user get fedora to begin with!?
-sv
On Mar 1, 2005, seth vidal skvidal@phy.duke.edu wrote:
On Tue, 2005-03-01 at 18:53 -0300, Alexandre Oliva wrote:
On Mar 1, 2005, seth vidal skvidal@phy.duke.edu wrote:
- so a user can report a bug (presumably by bugzilla, on the internet)
but can't download bzflag or tuxracer? How is that unavailable?
How about: internet access only from work, monitored downloads, no CD burning permitted, small amount of web browsing tolerated?
so how did the user get fedora to begin with!?
How about from a magazine?
Hi
so how did the user get fedora to begin with!?
How about from a magazine?
Linux for you in India distributed the fedora 3 dvd with one issue and includes all the updates till then in the next month but they said they would have preferred to distribute a single CD the first time. if there are any quick ways to build an ISO with the all the relevant updates it is a good idea to document it. Fedora should be have a organised way to target OEM's
===== Regards Rahul Sundaram
__________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
On Wed, 2005-03-02 at 09:51 -0800, Rahul Sundaram wrote:
Linux for you in India distributed the fedora 3 dvd with one issue and includes all the updates till then in the next month but they said they would have preferred to distribute a single CD the first time. if there are any quick ways to build an ISO with the all the relevant updates it is a good idea to document it. Fedora should be have a organised way to target OEM's
I think this is what you're looking for:
http://fedoranews.org/contributors/gene_czarcinski/update_distro/
Hi
I think this is what you're looking for:
http://fedoranews.org/contributors/gene_czarcinski/update_distro/
yes. thats part of the solution. thanks for the pointer. However fedora projects needs to do something like this in a official way. maybe update the ISO images every other week or so with all the updates till then. Targetting OEM's probably requires more than just this
===== Regards Rahul Sundaram
__________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
On Thu, 2005-03-03 at 02:01 -0800, Rahul Sundaram wrote:
yes. thats part of the solution. thanks for the pointer. However fedora projects needs to do something like this in a official way. maybe update the ISO images every other week or so with all the updates till then. Targetting OEM's probably requires more than just this
As an OEM thats not going to work. We master the original CDs with our logos and Fedora's logos and such. This is a rather large cost at release time, but we have to do it in a big chunk. To do this every week is insane. Instead we maintain an 'update' CD we burn manually and sticker label that we send w/ the system for re-install purposes. Making this CD available for use DURING install is a good goal.
On Thu, 2005-03-03 at 08:47 -0800, Jesse Keating wrote:
On Thu, 2005-03-03 at 02:01 -0800, Rahul Sundaram wrote:
yes. thats part of the solution. thanks for the pointer. However fedora projects needs to do something like this in a official way. maybe update the ISO images every other week or so with all the updates till then. Targetting OEM's probably requires more than just this
As an OEM thats not going to work. We master the original CDs with our logos and Fedora's logos and such. This is a rather large cost at release time, but we have to do it in a big chunk. To do this every week is insane. Instead we maintain an 'update' CD we burn manually and sticker label that we send w/ the system for re-install purposes. Making this CD available for use DURING install is a good goal.
Unfortunately, if you try to use it during the install process, you end up having to switch CDs a bazillion times due to package ordering concerns. That or you have to do some ugly things with precaching packages to be installed on the hard drive.
And that's assuming there aren't significant dependency changes that throw things more for a loop :/
Jeremy
On Thu, 2005-03-03 at 11:59 -0500, Jeremy Katz wrote:
Unfortunately, if you try to use it during the install process, you end up having to switch CDs a bazillion times due to package ordering concerns. That or you have to do some ugly things with precaching packages to be installed on the hard drive.
And that's assuming there aren't significant dependency changes that throw things more for a loop :/
sure, for inline usage. What about something less elegant, like 'Do you have an update CD? Oh you do? Lets install these updates now'. Sure it's ugly in that we already installed the package once, but it gets the job done. Thats essentially what I'm going now somehwhat manually w/ our post-install CDs.
On Mar 2, 2005, Rahul Sundaram rahulsundaram@yahoo.co.in wrote:
Linux for you in India distributed the fedora 3 dvd with one issue and includes all the updates till then in the next month but they said they would have preferred to distribute a single CD the first time.
I don't think the trademark use guidelines would allow them to do so, even if there was a documented procedure to do it. Ugh :-(
Hi
I don't think the trademark use guidelines would allow them to do so, even if there was a documented procedure to do it. Ugh :-(
Then the guidelines should be changed to accomodate this. Wasnt flexible trademark guidelines one of the changes for the rename to Fedora?
===== Regards Rahul Sundaram
__________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
On Thu, 2005-03-03 at 01:30 -0800, Rahul Sundaram wrote:
Then the guidelines should be changed to accomodate this. Wasnt flexible trademark guidelines one of the changes for the rename to Fedora?
It would certainly be useful if the trademark guidelines permitted one to build and distribute a DVD or set of CDs which contains _only_ Fedora Core, Fedora Extras and the official updates to those.
On Thu, 2005-03-03 at 10:33 +0000, David Woodhouse wrote:
On Thu, 2005-03-03 at 01:30 -0800, Rahul Sundaram wrote:
Then the guidelines should be changed to accomodate this. Wasnt flexible trademark guidelines one of the changes for the rename to Fedora?
It would certainly be useful if the trademark guidelines permitted one to build and distribute a DVD or set of CDs which contains _only_ Fedora Core, Fedora Extras and the official updates to those.
I think it might - but maybe we should get a clarification:
http://fedora.redhat.com/about/trademarks/guidelines/page4.html
They must only use the Fedora™ mark in association with the original Fedora™ code found on the Fedora Project website (see http://fedora.redhat.com/) without modification
Both extras and core are available here, and updates also.
http://fedora.redhat.com/about/trademarks/guidelines/page5.html
So we'd be shipping unmodified Fedora Core, Updates and Extras as a work. Which is still identifiable as Fedora. So I don't think we fall into the "seperate patches" category.
Paul
--- Paul Nasrat pnasrat@redhat.com wrote:
On Thu, 2005-03-03 at 10:33 +0000, David Woodhouse wrote:
On Thu, 2005-03-03 at 01:30 -0800, Rahul Sundaram
wrote:
Then the guidelines should be changed to
accomodate
this. Wasnt flexible trademark guidelines one of
the
changes for the rename to Fedora?
It would certainly be useful if the trademark
guidelines permitted one
to build and distribute a DVD or set of CDs which
contains _only_
Fedora Core, Fedora Extras and the official updates
to those.
I think it might - but maybe we should get a clarification:
http://fedora.redhat.com/about/trademarks/guidelines/page4.html
Yes a clarification regarding this is necessary. It would much better to have a FAQ which answers such questions explicitly.
===== Regards Rahul Sundaram
__________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
On Thu, 03 Mar 2005 11:07:33 +0000, Paul Nasrat pnasrat@redhat.com wrote:
So we'd be shipping unmodified Fedora Core, Updates and Extras as a work. Which is still identifiable as Fedora. So I don't think we fall into the "seperate patches" category.
unless of course you are talking about making changes to the installer image to make the installer process aware of an expanded package set. And there is the question of whether or not any installable mediaset can be considered 'unmodified' in the sense that the md5sums that make media-check work would change. Is it just the packages.. or is the installer image itself covered by the 'unmodified' language. Its far different to shove this all into a replacement installable image cd... than to gather packages to gether on a seperate cd. Even then on a seperate cd... are you allowed to generate repo metadata that differs from the original network repository? If you have a subset of packages the metadata will need to be regenerated.
In either case whether its allowed or not, I don't see it as clearly delineated enough in the guidelines. I would much rather see the trademark guidelines rewritten to give some very specific guidance for the most commonly expected usage case.... instead of being written for lawyers to read.
Exactly in what ways is a replacement set of installable media allowed to deviate from the original set? Can I include an Extras directory tree? Can I generate repo metadata for the Extras tree? Can I re-work the comps file to include more packages and groups? None of these questions are actually spelled out and they need to be.
-jef
On Thu, 2005-02-24 at 17:50 +0100, Matthias Saou wrote:
- Exim was removed... it's tiny, and was in FC3, so that's probably a bad idea.
I would suggest that removing a package that has significant security implications (any MTA or significant functionality network program would fall into this category) is not good. People depending on FC for security updates must be made aware that suddenly they must get security updates from elsewhere or change to an alternative package.
[I've not commented on this up until now because I do have an axe to grind, but I feel this aspect has been overlooked]
Nigel.
On Sun, 27 Feb 2005 14:49:32 +0000, Nigel Metheringham
I would suggest that removing a package that has significant security implications (any MTA or significant functionality network program would fall into this category) is not good. People depending on FC for security updates must be made aware that suddenly they must get security updates from elsewhere or change to an alternative package.
you touch on a larger issue about how a package vendor can effectively 'expire' any package to make sure users are aware its no longer being maintained by the original vendor. Currently such notifications for Core are made in the release-notes and its up to users installing the next release of Core to review the release notes. For extras I know of no discussion on how to address issues of notification of removals when they happen in the future. I think we can all agree that relying on the userbase to read the release-notes is probably a less effective method than some tool based approach that users/admins can interact with when doing normal update tasks. The closest thing we have right now in Core are yum and up2date's ability to list orphaned packages installed on the system that do not exist as part of a repository. But even this is a reactive step that users/admins must take to police theire own system. What we need is a way to have vendors 'push' a notice of expiration in a way that the tools notice and inform the admin about as a normal course of events. I know of no on-going experiments to implement anything like this.
-jef
On Feb 27, 2005, Jeff Spaleta jspaleta@gmail.com wrote:
you touch on a larger issue about how a package vendor can effectively 'expire' any package to make sure users are aware its no longer being maintained by the original vendor.
fedora-release could Obsolete: package <= V-R as of the time of the new release or something like that. It's not perfect, since if there's an update for the package after the initial release, one would have to spin a new fedora-release package to cover that. Yeah, right :-)
On 28 Feb 2005 19:04:08 -0300, Alexandre Oliva aoliva@redhat.com wrote:
fedora-release could Obsolete: package <= V-R as of the time of the new release or something like that. It's not perfect, since if there's an update for the package after the initial release, one would have to spin a new fedora-release package to cover that. Yeah, right :-)
obsoleting does more than notify.. it will have an affect on the install package set. Thats not what is need at all. people need to be informed of expiration so they can make informed choices... not have removals of expired packages removed by obsoleting magic. You only make matters worse by expanding the use of obsoleting to include this sort of situation... people will just learn to disable obsoleting to avoid applications evaporating from the system.
-jef
Jeff Spaleta wrote:
obsoleting does more than notify.. it will have an affect on the install package set. Thats not what is need at all. people need to be informed of expiration so they can make informed choices... not have removals of expired packages removed by obsoleting magic. You only make matters worse by expanding the use of obsoleting to include this sort of situation... people will just learn to disable obsoleting to avoid applications evaporating from the system.
What about adding metadata to the repos that describe packages that have been abandond. Then you could do a yum list abandond ( or the like ) to see what packages have become old/stale/abandond.
Though I just wonder how that would work if say core abandond a package, but freshrpms picked it up. Hmmm.....
Something to think about.
Cheers,
On Feb 28, 2005, Jeff Spaleta jspaleta@gmail.com wrote:
On 28 Feb 2005 19:04:08 -0300, Alexandre Oliva aoliva@redhat.com wrote:
fedora-release could Obsolete: package <= V-R as of the time of the
obsoleting does more than notify..
Could be Conflicts:, then.
On Thu, Feb 24, 2005 at 05:50:35PM +0100, Matthias Saou wrote:
- Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off".
And to debug 3D. We no longer have any way to debug 3D problems on Fedora with packages we know the client side of and build form.
On Tue, 2005-03-01 at 08:45 -0500, Alan Cox wrote:
And to debug 3D. We no longer have any way to debug 3D problems on Fedora with packages we know the client side of and build form.
Fedora Extras is not BUILT by community, just maintained. Packages will be built on a RH maintained build server/software.
On Tue, Mar 01, 2005 at 07:36:17AM -0800, Jesse Keating wrote:
Fedora Extras is not BUILT by community, just maintained. Packages will be built on a RH maintained build server/software.
Ok that works for me in this case. I just don't want to enter gentoospace where every user has a different binary
On Tue, 2005-03-01 at 10:38 -0500, Alan Cox wrote:
On Tue, Mar 01, 2005 at 07:36:17AM -0800, Jesse Keating wrote:
Fedora Extras is not BUILT by community, just maintained. Packages will be built on a RH maintained build server/software.
Ok that works for me in this case. I just don't want to enter gentoospace where every user has a different binary
When/where did you get the impression that random users' binaries would be uploaded for extras?
I'm asking b/c if this is a common impression I'd like to dispell it.
-sv
On Tue, Mar 01, 2005 at 10:45:17AM -0500, seth vidal wrote:
Ok that works for me in this case. I just don't want to enter gentoospace where every user has a different binary
When/where did you get the impression that random users' binaries would be uploaded for extras?
From the fact that extras build systems still seem to be under discussion
I'm asking b/c if this is a common impression I'd like to dispell it.
You just did 8)
From the fact that extras build systems still seem to be under discussion
ah, yes, the build system. Well at this moment, I'm the buildsystem. :) I have a couple of systems I keep the chroots on and build from there. I'm working with an assortment of others to have a build system that any random packager can install to test if their package builds cleanly in the environment that it will be built in for release.
it's a work in progress, of course.
-sv
Hi
When/where did you get the impression that random users' binaries would be uploaded for extras?
I'm asking b/c if this is a common impression I'd like to dispell it.
-sv
its not just his impression. I have heard it mentioned in several news sites and forums that fedora extras might not be reliable because random people will play with it. It might be a good idea to document how the process work in detail so I can point it to them the next time this FUD comes up anywhere
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
its not just his impression. I have heard it mentioned in several news sites and forums that fedora extras might not be reliable because random people will play with it. It might be a good idea to document how the process work in detail so I can point it to them the next time this FUD comes up anywhere
well it depends on what you mean by 'play with it'.
Fedora Extras allows people who are sponsored as packagers to add packages into the repository. They submit a src.rpm earlier on, normally some folks check through it to look for crack or legal problems. Then the packager checks it into cvs and a build request is made. The packages are built by the buildsystem and then pushed out to the repository.
wash, rinse, repeat.
They're all built in a known environment, but the packagers can be from all over the world.
Does that make sense?
all sorts of extras information here: http://fedoraproject.org/wiki/Extras
-sv
Hi
well it depends on what you mean by 'play with it'.
I meant add malicious stuff into it.
They're all built in a known environment, but the packagers can be from all over the world.
Does that make sense?
yes.
all sorts of extras information here: http://fedoraproject.org/wiki/Extras
ok. thanks
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
On Tue, 1 Mar 2005 07:44:15 -0800 (PST), Rahul Sundaram wrote:
When/where did you get the impression that random users' binaries would be uploaded for extras?
I'm asking b/c if this is a common impression I'd like to dispell it.
-sv
its not just his impression. I have heard it mentioned in several news sites and forums that fedora extras might not be reliable because random people will play with it.
Do you know of any news sites where such rumours have been spread? If it's just forum members, who are not Fedora Core users, it's not interesting. But _news sites_...?
Hi
Do you know of any news sites where such rumours have been spread? If it's just forum members, who are not Fedora Core users, it's not interesting. But _news sites_...?
its not reported as news that fedora extras in insecure or something stupid as that in any news site but comments in say osnews.com have had users who might be using fedora and are exhibiting doubts or others who are deliberately spreading misinformation to support some other distro.
===== Regards Rahul Sundaram
__________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
seth vidal wrote:
When/where did you get the impression that random users' binaries would be uploaded for extras?
I think many people still get the impression that Fedora Extras is in some way correlated to Red Hat Contrib where users did submit their own binaries. When really its processes are more like Red Hat's old Powertools. Just a thought.
I'm asking b/c if this is a common impression I'd like to dispell it.
Consider the job done.
-sb
-sv
On Tue, 2005-03-01 at 12:33 -0500, Stan Bubrouski wrote:
seth vidal wrote:
When/where did you get the impression that random users' binaries would be uploaded for extras?
I think many people still get the impression that Fedora Extras is in some way correlated to Red Hat Contrib where users did submit their own binaries. When really its processes are more like Red Hat's old Powertools. Just a thought.
Yes, much more like powertools. Not at all like contrib. And if it starts to be like contrib well, we have baseball bats and hammers to fix that problem. :)
-sv
On Tue, Mar 01, 2005 at 03:12:03PM -0500, seth vidal wrote:
Yes, much more like powertools. Not at all like contrib. And if it
I'm hoping "significantly better maintained than powertools", especially near the end there. As per (Fedora Core -- see my earlier post) non-objective #3.
On Tue, 2005-03-01 at 10:38 -0500, Alan Cox wrote:
On Tue, Mar 01, 2005 at 07:36:17AM -0800, Jesse Keating wrote:
Fedora Extras is not BUILT by community, just maintained. Packages
will
be built on a RH maintained build server/software.
Ok that works for me in this case. I just don't want to enter gentoospace where every user has a different binary
That indeed is a scary prospect. The Fedora Extras build server (not yet finished) has the goal of being self-hosting in FC, built from 100% FOSS, easy to setup so that joe-endpackager can run a copy of it on their own system before submitting srpms to Extras for official build, and stable enough to be blessed by RH for use in their facility. I think this will work out well.
Alan Cox wrote:
- Both tuxracer and bzflag were removed, but many people (Havoc, Alan) definitely want at least one good 3D game to "show off".
And to debug 3D. We no longer have any way to debug 3D problems on Fedora with packages we know the client side of and build form.
In my experience, xscreensaver is going to give the 3d hardware a much more extensive workout than any given game. Maybe this has changed in the latest Rawhide (I haven't checked) but it used to be that a Gnome install came with the full complement of 3D savers.
Also, more people run screen savers than tuxracer, so that's where the video driver crashes tend to occur. Then they blame me and I am sad.
On Tue, 1 Mar 2005, Jamie Zawinski wrote:
Also, more people run screen savers than tuxracer, so that's where the video driver crashes tend to occur. Then they blame me and I am sad.
Hehe, I've had several people complain about 'random' crashes, usually when they arrived at work in the morning or came back from coffee. All of them related to 3D screensavers :)
Maybe disabling 3D screensavers by default (and/or a warning about the potential to crash when people open the screensaver configuration) would reduce the uncomfortable (unstable) feeling people got when using Linux in these cases.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, Mar 02, 2005 at 01:24:58AM +0100, Dag Wieers wrote:
On Tue, 1 Mar 2005, Jamie Zawinski wrote:
Also, more people run screen savers than tuxracer, so that's where the video driver crashes tend to occur. Then they blame me and I am sad.
Hehe, I've had several people complain about 'random' crashes, usually when they arrived at work in the morning or came back from coffee. All of them related to 3D screensavers :)
Maybe disabling 3D screensavers by default (and/or a warning about the potential to crash when people open the screensaver configuration) would reduce the uncomfortable (unstable) feeling people got when using Linux in these cases.
Or how about just fixing the drivers so they don't lock up ? (reports to upstream DRI bugzilla at freedesktop.org, or $binary_driver_vendor_of_choice accordingly)
Dave
On Tue, 1 Mar 2005, Dave Jones wrote:
On Wed, Mar 02, 2005 at 01:24:58AM +0100, Dag Wieers wrote:
On Tue, 1 Mar 2005, Jamie Zawinski wrote:
Also, more people run screen savers than tuxracer, so that's where the video driver crashes tend to occur. Then they blame me and I am sad.
Hehe, I've had several people complain about 'random' crashes, usually when they arrived at work in the morning or came back from coffee. All of them related to 3D screensavers :)
Maybe disabling 3D screensavers by default (and/or a warning about the potential to crash when people open the screensaver configuration) would reduce the uncomfortable (unstable) feeling people got when using Linux in these cases.
Or how about just fixing the drivers so they don't lock up ?
People first have to know why it crashes before they know where to report it. The anecdotes I gave was to indicate that people usually don't know why it crashed and in return have a general feeling of unstability.
I would like to make sure that 1) these people don't have an uncomfortable feeling and 2) understand that enabling 3D has a potential to crash a system, so people might realise why it happens and where to report it.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, Mar 02, 2005 at 02:45:22AM +0100, Dag Wieers wrote:
On Tue, 1 Mar 2005, Dave Jones wrote:
On Wed, Mar 02, 2005 at 01:24:58AM +0100, Dag Wieers wrote:
On Tue, 1 Mar 2005, Jamie Zawinski wrote:
Also, more people run screen savers than tuxracer, so that's where the video driver crashes tend to occur. Then they blame me and I am sad.
Hehe, I've had several people complain about 'random' crashes, usually when they arrived at work in the morning or came back from coffee. All of them related to 3D screensavers :)
Maybe disabling 3D screensavers by default (and/or a warning about the potential to crash when people open the screensaver configuration) would reduce the uncomfortable (unstable) feeling people got when using Linux in these cases.
Or how about just fixing the drivers so they don't lock up ?
People first have to know why it crashes before they know where to report it. The anecdotes I gave was to indicate that people usually don't know why it crashed and in return have a general feeling of unstability.
I would like to make sure that 1) these people don't have an uncomfortable feeling and 2) understand that enabling 3D has a potential to crash a system, so people might realise why it happens and where to report it.
The problem is a "turning on this feature may crash you computer" dialog is enough to scare away a majority of users. Lowering the amount of testing something gets lowers the possibility of it ever getting reported, and subsequently fixed.
Dave
On Tue, 1 Mar 2005, Dave Jones wrote:
On Wed, Mar 02, 2005 at 02:45:22AM +0100, Dag Wieers wrote:
On Tue, 1 Mar 2005, Dave Jones wrote:
On Wed, Mar 02, 2005 at 01:24:58AM +0100, Dag Wieers wrote:
On Tue, 1 Mar 2005, Jamie Zawinski wrote:
Also, more people run screen savers than tuxracer, so that's where the video driver crashes tend to occur. Then they blame me and I am sad.
Hehe, I've had several people complain about 'random' crashes, usually when they arrived at work in the morning or came back from coffee. All of them related to 3D screensavers :)
Maybe disabling 3D screensavers by default (and/or a warning about the potential to crash when people open the screensaver configuration) would reduce the uncomfortable (unstable) feeling people got when using Linux in these cases.
Or how about just fixing the drivers so they don't lock up ?
People first have to know why it crashes before they know where to report it. The anecdotes I gave was to indicate that people usually don't know why it crashed and in return have a general feeling of unstability.
I would like to make sure that 1) these people don't have an uncomfortable feeling and 2) understand that enabling 3D has a potential to crash a system, so people might realise why it happens and where to report it.
The problem is a "turning on this feature may crash you computer" dialog is enough to scare away a majority of users. Lowering the amount of testing something gets lowers the possibility of it ever getting reported, and subsequently fixed.
I agree, though it probably depends on the exact wordings, it could be prefixed with: "Don't panic", in large friendly letters. :)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, Mar 02, 2005 at 03:05:04AM +0100, Dag Wieers wrote:
I agree, though it probably depends on the exact wordings, it could be prefixed with: "Don't panic", in large friendly letters. :)
Maybe all of the 3D drivers could flash "BUGGY 3D DRIVERS CAN CRASH YOUR SYSTEM" every 30th frame. Then, there'd be a 1/30th chance that when the system crashes, that's stuck displayed in the screen.
On Mer 2 mars 2005 2:45, Dag Wieers a écrit :
On Tue, 1 Mar 2005, Dave Jones wrote:
On Wed, Mar 02, 2005 at 01:24:58AM +0100, Dag Wieers wrote:
On Tue, 1 Mar 2005, Jamie Zawinski wrote:
Also, more people run screen savers than tuxracer, so that's where
the
video driver crashes tend to occur. Then they blame me and I am
sad.
Hehe, I've had several people complain about 'random' crashes,
usually
when they arrived at work in the morning or came back from coffee.
All of
them related to 3D screensavers :)
Maybe disabling 3D screensavers by default (and/or a warning about
the
potential to crash when people open the screensaver configuration)
would
reduce the uncomfortable (unstable) feeling people got when using
Linux in
these cases.
Or how about just fixing the drivers so they don't lock up ?
People first have to know why it crashes before they know where to report it. The anecdotes I gave was to indicate that people usually don't know why it crashed and in return have a general feeling of unstability.
What would be helpful is some script that went through all the screesavers sequentially so it'd be easier to test what screensaver is failing.
Pretty often when that happens to me the screen goes to sleep after a while and good luck finding what screensaver locked-up the box (yes I know I could do it manually - I just have other things to do than go through the full FC screensaver list with mouse and keyboard)
Regards,
Nicolas Mailhot wrote:
What would be helpful is some script that went through all the screesavers sequentially so it'd be easier to test what screensaver is failing.
while true; do xscreensaver-command -next; sleep 10; done
Pretty often when that happens to me the screen goes to sleep after a while and good luck finding what screensaver locked-up the box (yes I know I could do it manually - I just have other things to do than go through the full FC screensaver list with mouse and keyboard)
xscreensaver-command -exit xscreensaver -verbose >> LOG 2>&1
Then after you've unwedged the box, check the log.
On Mer 2 mars 2005 11:41, Jamie Zawinski a écrit :
Nicolas Mailhot wrote:
What would be helpful is some script that went through all the screesavers sequentially so it'd be easier to test what screensaver is failing.
while true; do xscreensaver-command -next; sleep 10; done
Pretty often when that happens to me the screen goes to sleep after a while and good luck finding what screensaver locked-up the box (yes I know I could do it manually - I just have other things to do than go through the full FC screensaver list with mouse and keyboard)
xscreensaver-command -exit xscreensaver -verbose >> LOG 2>&1
Then after you've unwedged the box, check the log.
Thanks! I just knew something like this must be possible. Shouldn't this be in a wiki somewhere? As other people noted, looping through the gl screensavers is a pretty effective way to test driver sanity.
Regards,
Nicolas Mailhot wrote:
Thanks! I just knew something like this must be possible. Shouldn't this be in a wiki somewhere?
/usr/share/doc/xscreensaver-*/README.debugging which is also http://www.jwz.org/xscreensaver/bugs.html
As other people noted, looping through the gl screensavers is a pretty effective way to test driver sanity.
You'd think this would have occured to the driver developers by now, wouldn't you? Evidence suggests not.
On Wed, Mar 02, 2005 at 01:24:58AM +0100, Dag Wieers wrote:
Hehe, I've had several people complain about 'random' crashes, usually when they arrived at work in the morning or came back from coffee. All of them related to 3D screensavers :)
The 3D screensavers don't seem to be the big problem always. The shipped ones are pretty dumb in terms of 3D usage anyway. We've actually had a longer history of problems with servers because there are utterly weird functions in X that come under the "hindsight" category which only Screen savers use
Maybe disabling 3D screensavers by default (and/or a warning about the potential to crash when people open the screensaver configuration) would reduce the uncomfortable (unstable) feeling people got when using Linux in these cases.
Or fix the 3D drivers - they are definitely getting a lot more stable now
Alan Cox wrote:
The 3D screensavers don't seem to be the big problem always. The shipped ones are pretty dumb in terms of 3D usage anyway. We've actually had a longer history of problems with servers because there are utterly weird functions in X that come under the "hindsight" category which only Screen savers use
Wow, that has totally not been my experience at all (either personally, or in the slew of "you crashed my server!" mail I get.) It's *always* one of the GL ones.
In fact, the only non-GL saver I can recall having gotten a crash report about was "blaster", which uses such esoteric functions as XDrawLine and XFillArc.
Years ago, Solaris used to like to crash if you use XSHM, but Linux never had that problem.
Or fix the 3D drivers - they are definitely getting a lot more stable now
I guess I must grudgingly agree with this.
After all, now that I'm running recent non-free nvidia drivers on a recent-but-not-too-recent card, it's the first time since I stopped using Irix in 1998 that I'm able to wake up to a non-wedged X server. Multiple days in a row!
Truly it is a new golden age.
On Tue, Mar 01, 2005 at 01:36:17PM -0800, Jamie Zawinski wrote:
And to debug 3D. We no longer have any way to debug 3D problems on Fedora with packages we know the client side of and build form.
In my experience, xscreensaver is going to give the 3d hardware a much more extensive workout than any given game. Maybe this has changed in the latest Rawhide (I haven't checked) but it used to be that a Gnome install came with the full complement of 3D savers.
Also, more people run screen savers than tuxracer, so that's where the video driver crashes tend to occur. Then they blame me and I am sad.
Don't feel sad, read DRI source code, and shift the blame accordingly :-) On a serious note, in my experience 3d screensaver crashes have been driver problems _every_ time I've looked into them, whether its been DRI, or binary drivers.
Dave
On Tue, 2005-03-01 at 13:36 -0800, Jamie Zawinski wrote:
Alan Cox wrote:
And to debug 3D. We no longer have any way to debug 3D problems on Fedora with packages we know the client side of and build form.
In my experience, xscreensaver is going to give the 3d hardware a much more extensive workout than any given game. Maybe this has changed in the latest Rawhide (I haven't checked) but it used to be that a Gnome install came with the full complement of 3D savers.
This used to be true for me too but the new "exercises 3D drivers like no other program" belongs to bzflag. Without fail every version has found something wrong in the binary nvidia drivers. The latest bzflag (version 2) now triggers a problem that causes X to take 100% of the CPU and nearly stops task switching completely.
On Wed, 2005-03-02 at 20:58 +0000, Sitsofe Wheeler wrote:
This used to be true for me too but the new "exercises 3D drivers like no other program" belongs to bzflag. Without fail every version has found something wrong in the binary nvidia drivers. The latest bzflag (version 2) now triggers a problem that causes X to take 100% of the CPU and nearly stops task switching completely.
This would be useful if we shipped Nvidia drivers. Oh wait, they're probably in Extras right?
Jesse Keating wrote:
On Wed, 2005-03-02 at 20:58 +0000, Sitsofe Wheeler wrote:
This used to be true for me too but the new "exercises 3D drivers like no other program" belongs to bzflag. Without fail every version has found something wrong in the binary nvidia drivers. The latest bzflag (version 2) now triggers a problem that causes X to take 100% of the CPU and nearly stops task switching completely.
This would be useful if we shipped Nvidia drivers. Oh wait, they're probably in Extras right?
It would be nice if Extras could be a network of Fedora/Red Hat certified repos hosted by individual hardware providers and software developers. FE would have one main list that tells the package update tool where to find the files. That would save Red Hat from trying to host every software for FCx on their server.
If that buildsystem that has been talked about actually materializes, it can be used for this effort. Instead of submitting the actual SRPM, the software/hardware vendor would host the binary rpms and FE would have the information to grab these rpms form that location. Most likely the current repo/metadata setup will have to be extended to handle this. Not that I want to take away from the work of repo maintainers. Perhaps 3rd party repos could be one of the sources in the certified list (for some individual packages not their entire repo). Also, proprietary software companies like skype and adobe, who don't want to release their source code but want to build their software for Fedora/Linux can utilizes this.
There would have to be a certification process ofcourse along with some other legalities.
Just an idea!
On Wed, 2005-03-02 at 17:20 -0500, Demond James wrote:
It would be nice if Extras could be a network of Fedora/Red Hat certified repos hosted by individual hardware providers and software developers. FE would have one main list that tells the package update tool where to find the files. That would save Red Hat from trying to host every software for FCx on their server.
That would be sortof nightmarish, the legalities alone boggle my feeble mind.
If that buildsystem that has been talked about actually materializes, it can be used for this effort. Instead of submitting the actual SRPM, the software/hardware vendor would host the binary rpms and FE would have the information to grab these rpms form that location. Most likely the current repo/metadata setup will have to be extended to handle this. Not that I want to take away from the work of repo maintainers. Perhaps 3rd party repos could be one of the sources in the certified list (for some individual packages not their entire repo). Also, proprietary software companies like skype and adobe, who don't want to release their source code but want to build their software for Fedora/Linux can utilizes this.
Extras can only contain FOSS.
There would have to be a certification process ofcourse along with some other legalities.
Just an idea!
Elliot Lee wrote:
On Thu, 24 Feb 2005, Gene C. wrote:
- I agree with those who want to expand the FC4 set to 5 CD images and
then put the big reduction effort into the FC5 timeframe when anaconda can/should be able to handle multiple "respositories" (and, homefully, pup also).
Something that needs to be mentioned - it was decided that it was better to go to 5 CDs for now than to kick eclipse and the Java stuff out. However, there is plenty of other stuff that can be moved to Extras right now, and as you've seen that has already been happening (maintainers still wanted for some of that stuff!).
1) I would like to volunteer ti maintain some packages 2) list of packages please which need maintainer please.
Regards,
Hans
On Thu, 2005-02-24 at 18:02 +0100, Hans de Goede wrote:
Elliot Lee wrote:
On Thu, 24 Feb 2005, Gene C. wrote:
- I agree with those who want to expand the FC4 set to 5 CD images and
then put the big reduction effort into the FC5 timeframe when anaconda can/should be able to handle multiple "respositories" (and, homefully, pup also).
Something that needs to be mentioned - it was decided that it was better to go to 5 CDs for now than to kick eclipse and the Java stuff out. However, there is plenty of other stuff that can be moved to Extras right now, and as you've seen that has already been happening (maintainers still wanted for some of that stuff!).
- I would like to volunteer ti maintain some packages
- list of packages please which need maintainer please.
http://fedoraproject.org/wiki/Extras_2fOrphanedPackages
-sv
On Thursday 24 February 2005 17:56, seth vidal wrote:
Notice that there it appears:
Packages without maintainer in Fedora Extras ... python-numeric ...
Yet according to the rawhide report of 20050222 we have: New package Numeric Numerical Extension to Python
This is interesting in the sense that it also raises the question regarding the package name that is being taken by Tom 'spot' Callaway:
http://fedoraproject.org/wiki/PackageNamingGuidelines
Probably this is a good time for a definitive for this package. :-)
-sv
Just my 0.02 €. :-)
On Thu, 2005-02-24 at 18:13 +0000, Jose' Matos wrote:
On Thursday 24 February 2005 17:56, seth vidal wrote:
Notice that there it appears:
Packages without maintainer in Fedora Extras ... python-numeric ...
Yet according to the rawhide report of 20050222 we have: New package Numeric Numerical Extension to Python
This is interesting in the sense that it also raises the question regarding the package name that is being taken by Tom 'spot' Callaway:
http://fedoraproject.org/wiki/PackageNamingGuidelines
Probably this is a good time for a definitive for this package. :-)
And this is currently being fixed. The package Numeric is coming out of core and python-numeric is moving to core.
Thanks for pointing it out, you have a good point.
-sv
On Thu, 24 Feb 2005, Jose' Matos wrote:
On Thursday 24 February 2005 17:56, seth vidal wrote:
Notice that there it appears:
Packages without maintainer in Fedora Extras ... python-numeric ...
Yet according to the rawhide report of 20050222 we have: New package Numeric Numerical Extension to Python
This is interesting in the sense that it also raises the question regarding the package name that is being taken by Tom 'spot' Callaway:
I believe it should change to python-numeric in Core - RSN.
-- Elliot
On Thu, 2005-02-24 at 18:13 +0000, Jose' Matos wrote:
Packages without maintainer in Fedora Extras ... python-numeric ...
Yet according to the rawhide report of 20050222 we have: New package Numeric Numerical Extension to Python
Yeah, but someone went a little nutty last night and a whole load of stuff got trashed which hadn't been expected to disappear -- hopefully only temporarily, since we've now acknowledged that we'd not going to manage to fit FC4/i386 onto 4 CDs.
So nutty that the i386 install tree didn't even build this morning, and no new mail was sent, afaict.
"sv" == seth vidal skvidal@phy.duke.edu writes:
sv> http://fedoraproject.org/wiki/Extras_2fOrphanedPackages
Does the fact that a package has been dropped from Core imply that it is orphaned?
- J<
Jason L Tibbitts III (tibbs@math.uh.edu) said:
sv> http://fedoraproject.org/wiki/Extras_2fOrphanedPackages
Does the fact that a package has been dropped from Core imply that it is orphaned?
Um, 'maybe'. I think some of the input method stuff was going to be imported by the i18n group. I'd suggest asking the maintainer if they're intending on maintaining any package you're interested in picking up. Even if they do want to maintain it in Extras, I doubt they'd mind a helping hand.
Bill
On Thu, 2005-02-24 at 17:25 -0500, Bill Nottingham wrote:
Does the fact that a package has been dropped from Core imply that it is orphaned?
Um, 'maybe'. I think some of the input method stuff was going to be imported by the i18n group. I'd suggest asking the maintainer if they're intending on maintaining any package you're interested in picking up. Even if they do want to maintain it in Extras, I doubt they'd mind a helping hand.
There's no point in maintaining dropped packages in Extras until Fedora can actually handle Extras properly.
People who require the overzealously pruned packages can just skip FC4 and wait until FC5, at which point upgrades from FC3 should hopefully be working again.
Unless the slip for GCC4 is going to give us enough time to do the multi-repo thing in anaconda?
On Thu, Feb 24, 2005 at 11:31:54PM +0000, David Woodhouse wrote:
There's no point in maintaining dropped packages in Extras until Fedora can actually handle Extras properly.
People who require the overzealously pruned packages can just skip FC4 and wait until FC5, at which point upgrades from FC3 should hopefully be working again.
Or at the very least there's actually a link from the FC webpage to Extras so that people can find it. (Continuing to bug and remind, per request.)
John Thacker
On Thu, 24 Feb 2005 23:31:54 +0000, David Woodhouse dwmw2@infradead.org wrote:
There's no point in maintaining dropped packages in Extras until Fedora can actually handle Extras properly.
That's a bit over the top.... there is most certaintly benefit it maintaining dropped packages in Extras.
is it the ideal situation? no... but if Red Hat decides to drop anything for whatever reason... space constraints, labor constraints, phase of the moon, or pure malicious spite, whatever reason... there is certaintly benefit to the community at large in providing those packages in Extras if there is a community member willing to maintain the package.
We can argue all day and all night about the reasons why packages are dropped from Core... as the multiple threads on the topic have proven....but if the alternative is to not have the package available at all or to have the package available in Extras... clearly.. there is benefit in maintaining it in Extras compared to letting go unpackaged.
Holding our collective breath while we cross our arms and make 4 year old pouting faces in an effort to demand the decision be reversed only makes a bad situation worse. Packages are dropped pretty much every release.. even back in rhl. We can dislike the decision... but at the end of the day its better of having the packages available than not if there are people to maintain it in Extras and a demand for it.
-jef"takes his ball and goes home... oh wait i am home"spaleta
On Thu, 2005-02-24 at 23:31 +0000, David Woodhouse wrote:
There's no point in maintaining dropped packages in Extras until Fedora can actually handle Extras properly.
Isn't that a bit of an overstatement? Realistically, if you install FC4 later than on the day it is released you'll likely want to do a "yum update" pretty much immediately. If Extras is enabled by default in Yum (and any other package managers that are deemed to matter), this will also pull in the updates for anything that was moved into Extras. Sure, that's a two-stage upgrade (anaconda + yum), but with the amount of package updates that Fedora has been seeing, it basically is anyways.
From what I have understood it sure sounds like the Extras repo is
supposed to be enabled by default?
Cheers, Per
David Woodhouse wrote:
People who require the overzealously pruned packages can just skip FC4 and wait until FC5, at which point upgrades from FC3 should hopefully be working again.
Wha?? Upgrades from FC3 -> FC4 are not going to work? I must have missed something. Can someone confirm that this is true, or better yet, not true? If there's no upgrade path from FCX -> FCY, then the six month release cycle + Red Hat's EOL policy will orphan users on un-upgradeable systems.
<quote who="Aaron Bennett">
David Woodhouse wrote:
People who require the overzealously pruned packages can just skip FC4 and wait until FC5, at which point upgrades from FC3 should hopefully be working again.
Wha?? Upgrades from FC3 -> FC4 are not going to work? I must have missed something. Can someone confirm that this is true, or better yet, not true? If there's no upgrade path from FCX -> FCY, then the six month release cycle + Red Hat's EOL policy will orphan users on un-upgradeable systems.
Is this not the nature of RPMS? A seemless upgrade path?
-- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
Wha?? Upgrades from FC3 -> FC4 are not going to work? I must have missed something. Can someone confirm that this is true, or better yet, not true? If there's no upgrade path from FCX -> FCY, then the six month release cycle + Red Hat's EOL policy will orphan users on un-upgradeable systems.
upgrades from fc3->fc4 will work, just like anything else. David is fear-mongering a bit.
At the worst case once the system is upgraded via anaconda you'll need to run yum update to make sure any packages once in extras are moved over.
-sv
seth vidal wrote:
upgrades from fc3->fc4 will work, just like anything else. David is fear-mongering a bit.
At the worst case once the system is upgraded via anaconda you'll need to run yum update to make sure any packages once in extras are moved over.
-sv
Excellent. I hoped that would be the case. Was I just trolled? :-)
On Fri, 2005-02-25 at 09:31 -0500, Aaron Bennett wrote:
Wha?? Upgrades from FC3 -> FC4 are not going to work? I must have missed something. Can someone confirm that this is true, or better yet, not true? If there's no upgrade path from FCX -> FCY, then the six month release cycle + Red Hat's EOL policy will orphan users on un-upgradeable systems.
It depends on the packages you have installed. As it stands, some packages which were in FC3 are missing from the rawhide tree -- so an upgrade will not be able to update the complete package set. The will leave outdated packages installed -- whether that causes problems or not depends on the package and its dependencies. If it's built against versions of shared libraries which are no longer present, then I believe the installer will have removed the old version of those libraries and will have left the package in question broken. That may be your MTA or your X environment -- nothing important :)
As Seth says, you may be able to update the missing packages separately to remedy this, if Extras has actually come together and has those packages in a usable form by the time you upgrade.
By the time FC5 happens, however, Extras should be working properly and the installer should handle it -- an upgrade should work properly as before. That's why many people are requesting that we postpone the package-killing spree until FC5 instead of doing it now.
The upgrade/EOL schedules basically give you the leeway to skip a Fedora release and upgrade from N to N+2. If FC4 doesn't regain the missing packages, I suspect I'll just be leaving most of my machines running FC3 until FC5 is released, and update them then. The ones which were FC2 and waiting till FC4 will be updated to FC3 and then wait till FC5.
Once upon a time, David Woodhouse dwmw2@infradead.org said:
If it's built against versions of shared libraries which are no longer present, then I believe the installer will have removed the old version of those libraries and will have left the package in question broken.
Do you have evidence to back that up? Does anaconda somehow disable the normal dependency checking? Normally, rpm would refuse to remove a library that is still required by another installed RPM.
I can see that you would be unable to upgrade if:
- existing RPM xyzzy required libfoo.so.1 - existing RPM libfoo-1.0 provides libfoo.so.1 - RPM xyzzy was moved from Core to Extras (so unavailable for FC4 install) - new RPM libfoo-2.0 provides libfoo.so.2 - new RPM system-config-bar requires libfoo.so.2 and is in the default install
If there isn't a compat-libfoo that provides libfoo.so.1, you would be stuck. The question is: what would anaconda do in that case? Would it abort installation because dependencies cannot be satisfied, or would it attempt to upgrade anyway (and break either RPM xyzzy or RPM system-config-bar)?
Hi.
Chris Adams cmadams@hiwaay.net wrote:
Does anaconda somehow disable the normal dependency checking?
Yes.
On Fri, 2005-02-25 at 08:53 -0600, Chris Adams wrote:
Once upon a time, David Woodhouse dwmw2@infradead.org said:
If it's built against versions of shared libraries which are no longer present, then I believe the installer will have removed the old version of those libraries and will have left the package in question broken.
Do you have evidence to back that up? Does anaconda somehow disable the normal dependency checking? Normally, rpm would refuse to remove a library that is still required by another installed RPM.
I can see that you would be unable to upgrade if:
- existing RPM xyzzy required libfoo.so.1
- existing RPM libfoo-1.0 provides libfoo.so.1
- RPM xyzzy was moved from Core to Extras (so unavailable for FC4 install)
- new RPM libfoo-2.0 provides libfoo.so.2
- new RPM system-config-bar requires libfoo.so.2 and is in the default install
Unfortunately, most library packages in Fedora aren't packaged nearly so intelligently. Worse, many library packages aren't even split from applications (curl utility vs libcurl, for example - both come in a single package) so all sorts of unfortunate situations arise when you use a package not in Core (or Extras, once that's fully integrated) that depends on a library that gets upgraded in the next release. And, unfortunately, real people generally do need or want a package or three not supplied by Fedora, so these issues pop up regularly.
Every bug I've filed pointing out the problem caused by poorly packaged libraries gets closed with a message that's the equivalent of, "This isn't worth our time, you must eat babies if you use packages outside of Core, and there's no real advantage at all to not breaking stuff, so go away."
Kind of frustrating, to say the least...
If there isn't a compat-libfoo that provides libfoo.so.1, you would be stuck. The question is: what would anaconda do in that case? Would it
Or what happens in FC+2 where compat-libfoo doesn't provide libfoo.so.1 anymore, but now only provides libfoo.so.2? The entire compat-* is so incredibly brain damaged and poorly conceived that I am honestly shocked it's actually lived this long. If you're going to have multiple packages provide multiple versions of a library, name the package according to the version it supplies, so you can actually have *many* versions of a library installed (if you need it) without needing to do manual rpm -i foo-hackery that tends to break all sorts of useful things (like upgrades).
abort installation because dependencies cannot be satisfied, or would it attempt to upgrade anyway (and break either RPM xyzzy or RPM system-config-bar)?
-- Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Fri, 2005-02-25 at 08:53 -0600, Chris Adams wrote:
Once upon a time, David Woodhouse dwmw2@infradead.org said:
If it's built against versions of shared libraries which are no longer present, then I believe the installer will have removed the old version of those libraries and will have left the package in question broken.
Do you have evidence to back that up? Does anaconda somehow disable the normal dependency checking? Normally, rpm would refuse to remove a library that is still required by another installed RPM.
anaconda does disable normal dep checking if it can't resolve something, that's true - however, it doesn't remove stuff.
-sv
On Fri, 2005-02-25 at 10:08 -0500, seth vidal wrote:
anaconda does disable normal dep checking if it can't resolve something, that's true - however, it doesn't remove stuff.
Let's consider an example. You have an FC2 system with Acrobat 7 installed, which uses libcurl.so.2.
You update to FC3. What does anaconda do with the curl-7.11.1-1 package and hence /usr/lib/libcurl.so.2? Does it not remove it and replace it with a new package that no longer provides libcurl.so.2?
My understanding is that anaconda will remove the old curl package and install a new one, and that the Acrobat reader will no longer run. Are you suggesting that that's that _not_ what happens? That anaconda doesn't remove stuff? That out-of-Core packages don't ever get broken by upgrades?
By FC5, anaconda should handle Extras properly and everything should be fine. We can start moving packages to Extras in a controlled fashion and cut Core down to a minimum -- that makes a lot of sense.
What _doesn't_ make sense is doing it right now in a mad rush. Especially if we're not going to achieve the goal of cutting the i386 install to 4 CDs anyway -- regardless of the question of whether that's a worthwhile thing to be attempting in the first place.
On Fri, 2005-02-25 at 15:47 +0000, David Woodhouse wrote:
On Fri, 2005-02-25 at 10:08 -0500, seth vidal wrote:
anaconda does disable normal dep checking if it can't resolve something, that's true - however, it doesn't remove stuff.
Let's consider an example. You have an FC2 system with Acrobat 7 installed, which uses libcurl.so.2.
You update to FC3. What does anaconda do with the curl-7.11.1-1 package and hence /usr/lib/libcurl.so.2? Does it not remove it and replace it with a new package that no longer provides libcurl.so.2?
My understanding is that anaconda will remove the old curl package and install a new one,
That's called upgrading, not removing stuff :)
and that the Acrobat reader will no longer run. Are you suggesting that that's that _not_ what happens? That anaconda doesn't remove stuff? That out-of-Core packages don't ever get broken by upgrades?
What Seth means by anaconda not removing stuff is that in your example, assuming that acroread was installed as an rpm, anaconda wouldn't remove acroread because it's dependencies couldn't be matched, it just leaves the package with it's broken dependencies alone.
- Panu -
On Fri, 2005-02-25 at 17:59 +0200, Panu Matilainen wrote:
What Seth means by anaconda not removing stuff is that in your example, assuming that acroread was installed as an rpm, anaconda wouldn't remove acroread because it's dependencies couldn't be matched, it just leaves the package with it's broken dependencies alone.
Right. Anaconda doesn't actually remove the out-of-Core package itself -- nobody suggested that it does. But it still doesn't actually _work_ if the libraries on which it depends have been removed.
Btw, http://angryflower.com/itsits.gif :)
On Fri, 2005-02-25 at 16:03 +0000, David Woodhouse wrote:
On Fri, 2005-02-25 at 17:59 +0200, Panu Matilainen wrote:
What Seth means by anaconda not removing stuff is that in your example, assuming that acroread was installed as an rpm, anaconda wouldn't remove acroread because it's dependencies couldn't be matched, it just leaves the package with it's broken dependencies alone.
Right. Anaconda doesn't actually remove the out-of-Core package itself -- nobody suggested that it does. But it still doesn't actually _work_ if the libraries on which it depends have been removed.
so you're really only dealing with obsoletes.
oh and anaconda has no way of dealing with closed source binaries really anyway - on any version of anaconda, ever.
and since things have been removed from rhl and fc in the past - your argument is just a straw man.
BTW,. you're being a dick.
-sv
Once upon a time, seth vidal skvidal@phy.duke.edu said:
On Fri, 2005-02-25 at 16:03 +0000, David Woodhouse wrote:
Right. Anaconda doesn't actually remove the out-of-Core package itself -- nobody suggested that it does. But it still doesn't actually _work_ if the libraries on which it depends have been removed.
so you're really only dealing with obsoletes.
You are dealing with the fact that anaconda can't handle non-Core packages and that it can break any installed non-Core package (including packages that were previously in Core but now are not).
oh and anaconda has no way of dealing with closed source binaries really anyway - on any version of anaconda, ever.
Red herring - anaconda has no way of dealing with any kind of source and it doesn't know (or care) about the difference in the license or where the package came from (other than "current Core"). Throwing the "closed source" arguement is just trying to ignore the problem or blame it on someone else.
On Fri, 2005-02-25 at 10:19 -0600, Chris Adams wrote:
Once upon a time, seth vidal skvidal@phy.duke.edu said:
On Fri, 2005-02-25 at 16:03 +0000, David Woodhouse wrote:
Right. Anaconda doesn't actually remove the out-of-Core package itself -- nobody suggested that it does. But it still doesn't actually _work_ if the libraries on which it depends have been removed.
so you're really only dealing with obsoletes.
You are dealing with the fact that anaconda can't handle non-Core packages and that it can break any installed non-Core package (including packages that were previously in Core but now are not).
but it doesn't break them in the since that it's non-functional - it just makes them go away for the first boot.
oh and anaconda has no way of dealing with closed source binaries really anyway - on any version of anaconda, ever.
Red herring - anaconda has no way of dealing with any kind of source and it doesn't know (or care) about the difference in the license or where the package came from (other than "current Core"). Throwing the "closed source" arguement is just trying to ignore the problem or blame it on someone else.
Not really, the open source ones could feasibly be included in fedora core and therefore could deal with it. The closed source items cannot.
-sv
Once upon a time, seth vidal skvidal@phy.duke.edu said:
Red herring - anaconda has no way of dealing with any kind of source and it doesn't know (or care) about the difference in the license or where the package came from (other than "current Core"). Throwing the "closed source" arguement is just trying to ignore the problem or blame it on someone else.
Not really, the open source ones could feasibly be included in fedora core and therefore could deal with it. The closed source items cannot.
So then we'd be back to Fedora Core being 11 CDs, because everything would have to be included.
On Fri, 25 Feb 2005 10:19:27 -0600, Chris Adams cmadams@hiwaay.net wrote:
Red herring - anaconda has no way of dealing with any kind of source and it doesn't know (or care) about the difference in the license or where the package came from (other than "current Core"). Throwing the "closed source" arguement is just trying to ignore the problem or blame it on someone else.
No one is ignoring the problem... he's pointing out this problem has always existed and will continue to exist for a class of software for which repositories won't exist. My Absoft fortran compiler for example.. won't ever show up in an online repository built explicitly for fedora... but i am able to upgrade the system and fix its deps once i reboot.
No one is ignoring the problem... packages have been dropped in previous releases even way back in rhl... when there was no Extras. If all the java stuff was ready for fc1 or fc2 or rhl9.. we have the same problem... with the same solution. If anything the fact that there is a plan for fc5 to resolve the "long term" problem says that its not being ignored. There is a constant balancing between long term interests and short term interests... this round is not very different than the last 8 releases.
-jef
On Fri, 25 Feb 2005, Jeff Spaleta wrote:
No one is ignoring the problem... packages have been dropped in previous releases even way back in rhl... when there was no Extras. If all the java stuff was ready for fc1 or fc2 or rhl9.. we have the same problem... with the same solution. If anything the fact that there is
I think everyone wants the same things, to make sure FC4 does not turn into an end user nightmare. Personally my vote would be for 5 cd's until a true fix can be applied rather than a last minute pulling of packages. But seeing as that may not be happening.
The problem that I and others see is that people using core could update and find a broken system. Yes, this is something yum could fix, but if the user is using CD's they may not have access to update at that point. So the people that use CD because they don't have broadband are going to be the poeple hardest hit by these changes.
I just don't wat to alienate those users who just invested a number of hours to upgrade to fc4.
( forgive me if this exists already ) What if anaconda mearly warned people that the following packages will have unsatified dependancies at the end of the install and that the person may/will need access to extras and or access to the internet to complete installation? This would allow people to know what they were getting into and decide if the wanted to upgrade immediatly and break things or wait. It's not the perfect solution, but at least it allows users to make an informed decision about proceeding with the upgrade IF they are affected by the loss of packages in core. People unaffected would install as they always have.
Cheers, Eric Warnke
Systems Admin - Research Technology SUNY at Albany
On Fri, 2005-02-25 at 11:56 -0500, Eric Warnke wrote:
On Fri, 25 Feb 2005, Jeff Spaleta wrote:
No one is ignoring the problem... packages have been dropped in previous releases even way back in rhl... when there was no Extras. If all the java stuff was ready for fc1 or fc2 or rhl9.. we have the same problem... with the same solution. If anything the fact that there is
I think everyone wants the same things, to make sure FC4 does not turn into an end user nightmare. Personally my vote would be for 5 cd's until a true fix can be applied rather than a last minute pulling of packages. But seeing as that may not be happening.
That's been true forever if you EVER installed a former release and either: 1. had ANY package removed which you used (lprng anyone?) 2. ever installed something from fedora.us, freshrpms, dagrpms, atrpms, etc etc etc
b/c those deps wouldn't be accounted for in the installer.
This isn't new.
-sv
On Fri, 25 Feb 2005, seth vidal wrote:
I think everyone wants the same things, to make sure FC4 does not turn into an end user nightmare. Personally my vote would be for 5 cd's until a true fix can be applied rather than a last minute pulling of packages. But seeing as that may not be happening.
That's been true forever if you EVER installed a former release and either:
- had ANY package removed which you used (lprng anyone?)
lprng was never part of core ( afaict )
- ever installed something from fedora.us, freshrpms, dagrpms, atrpms,
I don't install things from fedora.us, freshrpms, dag, ... if I need something outside core I rebuild it, test it and deploy it in a local repo. I don't think it's unreasonable to let the user know that they are breaking there system in anaconda.
But that's not the point. FC1 was 3 discs, FC2 was 4 discs and there was a grand total of 21 packages removed ( list below ) and 128 additional packages. FC3 was 4 discs as well and there were 53 packages removed from the system ( list below ) and 78 additions. Of these packages removed MOST were because java was pulled and therefore the associated packages were also pulled. Looking at these lists it's clear that the vast majority of these packages were removed because or age, or neglect.
In contrast, with this round of cuts you are asking for and removing packages that are not neglected or obsolete but packages at that are regularly used by members of this list.
I don't think it's outragious of the community to ask why those packages have been removed with such haste? Why a 5 disc FC4 is such a problem? Why not better inform the user with anaconda? Might I remind RedHat that they floated the question to the community without any standards of what or why. No attempt has been made to clarify the exact ammount of space that need to be made up. No one has attempted to bzip2 packages that might save space. Between suggestions already made we could reduce the overage by half. Careful inspection of the packages could reveal more dead packages and then larger items could be examined for cutting.
Cheers, Eric
Packages removed from FC2 -Xbae -Xlt -ami -bonobo-conf -boost-jam -cipe -gnome-vfs2-extras -imap -indexhtml -kdoc -kpppload -libcapplet0 -libgtop -libmrproject -mars-nwe -mrproject -nmh -run -xawtv -xcpustate -xtraceroute
Packages removed from FC3 -Gtk-Perl -Wnn6-SDK -ac-archive -ant -aspell-pt_BR -bcel -bluez-pan -bluez-sdp -chromium -commons-beanutils -commons-collections -commons-dbcp -commons-digester -commons-fileupload -commons-logging -commons-modeler -commons-pool -cup -dvdrtools -glade -gqview -gtkam -gtkglarea -hwcrypto -iiimf-le-inpinyin -iscsi -jaf -jakarta-regexp -javamail -junit -libole2 -librep -licq -linc -mx4j -mysql-jdbc -njamd -pidentd -pilot-link095-compat -python-optik -quanta -redhat-java-rpm-scripts -rep-gtk -sawfish -servletapi -shapecfg -struts -system-config-proc -tomcat -unarj -xalan-j -xerces-j
On Fri, 25 Feb 2005 15:07:46 -0500 (EST), Eric Warnke wrote:
In contrast, with this round of cuts you are asking for and removing packages that are not neglected or obsolete but packages at that are regularly used by members of this list.
That's _the_ opportunity for such members to step forward and maintain the packages in Fedora Extras, provided that the previous maintainer at Red Hat hasn't planned to do that.
No one has attempted to bzip2 packages that might save space.
I remember a long discussion about time/space tradeoffs. bzip2 uncompression is a lot slower than gzip.
On Fri, 25 Feb 2005 21:28:31 +0100, Michael Schwendt fedora@wir-sind-cool.org wrote:
That's _the_ opportunity for such members to step forward and maintain the packages in Fedora Extras, provided that the previous maintainer at Red Hat hasn't planned to do that.
Yeah, but if there is some software package I like, I'm more inclined to install it from source rather than to screw around with rpms... Be that finding a prebuilt one that's six months out of date or going through the extra bother to generate rpms.
I've built rpms before, but the question I'd have then is what would be expected of me if I ~were~ to maintain a package myself. It's easy for me to test on AMD64 and (possibly) x86, but I'm not going to be able to support a package for the Itanic.
No one has attempted to bzip2 packages that might save space.
I remember a long discussion about time/space tradeoffs. bzip2 uncompression is a lot slower than gzip.
On newer computers (>1 GhZ) I think that the installation time is more determined by the speed of the I/O system than the speed of the CPU. bzip might actually help.
No one has attempted to bzip2 packages that might save space.
I remember a long discussion about time/space tradeoffs. bzip2 uncompression is a lot slower than gzip.
On newer computers (>1 GhZ) I think that the installation time ismore determined by the speed of the I/O system than the speed of the CPU. bzip might actually help.
I believe that switching would increase the minimum memory requirements for Anaconda.
Yeah, but if there is some software package I like, I'm more inclined to install it from source rather than to screw around with rpms... Be that finding a prebuilt one that's six months out of date or going through the extra bother to generate rpms.
I've built rpms before, but the question I'd have then is what would be expected of me if I ~were~ to maintain a package myself. It's easy for me to test on AMD64 and (possibly) x86, but I'm not going to be able to support a package for the Itanic.
That's not expected. Maintainers are expected to: - keep the package building on whatever they can and solicit help from people running on minority platforms for testing - monitor the software for updates and security issues - stay current with the expected and intended use for the package - keep abreast of licensing issues with the package. - keep the packaging guidelines applied and cleanly implemented in the package.
-sv
Le vendredi 25 février 2005 à 15:07 -0500, Eric Warnke a écrit :
I don't think it's outragious of the community to ask why those packages have been removed with such haste? Why a 5 disc FC4 is such a problem? Why not better inform the user with anaconda? Might I remind RedHat that they floated the question to the community without any standards of what or why. No attempt has been made to clarify the exact ammount of space that need to be made up.
Already lengthily discussed here (fedora-devel).
On Fri, Feb 25, 2005 at 03:07:46PM -0500, Eric Warnke wrote:
lprng was never part of core ( afaict )
LPRng was in Red Hat Linux 9 and earlier.
I don't install things from fedora.us, freshrpms, dag, ... if I need something outside core I rebuild it, test it and deploy it in a local repo. I don't think it's unreasonable to let the user know that they are breaking there system in anaconda.
Anaconda won't upgrade your self-built packages, then. It won't remove them, either. Same as the packages removed from FC4.
or why. No attempt has been made to clarify the exact ammount of space that need to be made up. No one has attempted to bzip2 packages that might save space. Between suggestions already made we could reduce the overage by half. Careful inspection of the packages could reveal more dead packages and then larger items could be examined for cutting.
You could do this. Anyone who cared enough could.
It depends on the packages you have installed. As it stands, some packages which were in FC3 are missing from the rawhide tree -- so an upgrade will not be able to update the complete package set. The will leave outdated packages installed -- whether that causes problems or not depends on the package and its dependencies. If it's built against versions of shared libraries which are no longer present, then I believe the installer will have removed the old version of those libraries and will have left the package in question broken. That may be your MTA or your X environment -- nothing important :)
As Seth says, you may be able to update the missing packages separately to remedy this, if Extras has actually come together and has those packages in a usable form by the time you upgrade.
So the way I see it here are the items needed to make extras work for fc4:
1. branch fc3 off of devel in extras cvs 2. get release updates in extras cvs spec files 3. build world 4. look for things that break 5. wash, rinse, repeat.
What we don't need right now is a lot of fatalism.
-sv
On Fri, 2005-02-25 at 10:52 -0500, seth vidal wrote:
So the way I see it here are the items needed to make extras work for fc4:
- branch fc3 off of devel in extras cvs
- get release updates in extras cvs spec files
- build world
- look for things that break
- wash, rinse, repeat.
6. Add support to anaconda for multiple repositories (planned for FC5)
What we don't need right now is a lot of fatalism.
What we need is to do it in a controlled fashion; not just dump random packages when a release is imminent. Doing it in rawhide just after the release of FC4 would make sense, and then it will be fine in FC5.
On Fri, 2005-02-25 at 15:56 +0000, David Woodhouse wrote:
On Fri, 2005-02-25 at 10:52 -0500, seth vidal wrote:
So the way I see it here are the items needed to make extras work for fc4:
- branch fc3 off of devel in extras cvs
- get release updates in extras cvs spec files
- build world
- look for things that break
- wash, rinse, repeat.
- Add support to anaconda for multiple repositories (planned for FC5)
What we don't need right now is a lot of fatalism.
What we need is to do it in a controlled fashion; not just dump random packages when a release is imminent. Doing it in rawhide just after the release of FC4 would make sense, and then it will be fine in FC5.
Packages have been removed in every release. This isn't new.
-sv
Once upon a time, seth vidal skvidal@phy.duke.edu said:
Packages have been removed in every release. This isn't new.
In the past, packages were removed because they were no longer functional, not widely used, etc. They weren't just pushed to another location, they were dropped altogether.
What we are seeing now is a large scale dumping of packages with the excuse that they can go to Extras. However, since Extras isn't available at install, ISOs are not available for download, and anaconda can't handle dependencies, currently running software can be broken by upgrades.
In the past, packages were removed because they were no longer functional, not widely used, etc. They weren't just pushed to another location, they were dropped altogether.
What we are seeing now is a large scale dumping of packages with the excuse that they can go to Extras. However, since Extras isn't available at install, ISOs are not available for download, and anaconda can't handle dependencies, currently running software can be broken by upgrades.
anaconda can so handle dependencies it just doesn't currently have a way to talk to those repositories that have the dependencies.
-sv
On Fri, 2005-02-25 at 11:25 -0500, seth vidal wrote:
anaconda can so handle dependencies it just doesn't currently have a way to talk to those repositories that have the dependencies.
....so it can't handle them. Seth, you seem to be deliberately muddying the issue, just as with the red herring 'closed source' thing. I chose acroread 7 as an example of a package with dependencies on a library which is absent from a later version of Core. Whether you can get the source or not is entirely irrelevant.
Getting back to the point you were deviating from -- apparently the intention is that anaconda _will_ be able to handle such out-of-Core dependencies in FC5, which is why so many people are suggesting that the package-killing spree be postponed until FC5.
Getting back to the point you were deviating from -- apparently the intention is that anaconda _will_ be able to handle such out-of-Core dependencies in FC5, which is why so many people are suggesting that the package-killing spree be postponed until FC5.
and I'm explaining that the 'package killing spree' as you so colorfully have put it, is not anything new.
it's happened in EVERY RELEASE.
It just wasn't discussed.
which leads me to believe that, due to the reaction this time around, it won't be discussed in the future. It'll just happen.
-sv
Once upon a time, seth vidal skvidal@phy.duke.edu said:
and I'm explaining that the 'package killing spree' as you so colorfully have put it, is not anything new.
it's happened in EVERY RELEASE.
And as I've said, it didn't on such a large scale to things lots of people still used regularly.
It just wasn't discussed.
which leads me to believe that, due to the reaction this time around, it won't be discussed in the future. It'll just happen.
So much for Fedora being an "open" project.
On Fri, 2005-02-25 at 13:08 -0600, Chris Adams wrote:
Once upon a time, seth vidal skvidal@phy.duke.edu said:
and I'm explaining that the 'package killing spree' as you so colorfully have put it, is not anything new.
it's happened in EVERY RELEASE.
And as I've said, it didn't on such a large scale to things lots of people still used regularly.
It just wasn't discussed.
which leads me to believe that, due to the reaction this time around, it won't be discussed in the future. It'll just happen.
So much for Fedora being an "open" project.
So maybe I'm confused here. Maybe I'm lost, but what the hell do you think I'm doing? do you think red hat is secretly paying me to do this stuff? B/c if they are then i missed the pay checks.
open doesn't mean everyone's opinion is equal.
it means there is a way to understand what's happening.
But everytime someone brings up something on this list that is going to change the response is: NOOOOOOOOOOOOOOOOOOOOOOO IT CANNOT CHANGE. CHANGE IS BAD. DON'T CHANGE THINGS.
and it gets old.
why do you think fedora-maintainers is closed to posts from non-maintainers?
-sv
On Fri, 2005-02-25 at 14:15 -0500, seth vidal wrote:
So maybe I'm confused here. Maybe I'm lost, but what the hell do you think I'm doing?
Mostly being a muppet, since you ask.
But everytime someone brings up something on this list that is going to change the response is: NOOOOOOOOOOOOOOOOOOOOOOO IT CANNOT CHANGE. CHANGE IS BAD. DON'T CHANGE THINGS.
That's a very disingenuous misstatement of what people have asked for. A more honest summary would be:
"Don't make this change so hastily -- since we can do this properly in FC5, please let's do it then, when Extras is workable".
On Fri, 2005-02-25 at 19:46 +0000, David Woodhouse wrote:
On Fri, 2005-02-25 at 14:15 -0500, seth vidal wrote:
So maybe I'm confused here. Maybe I'm lost, but what the hell do you think I'm doing?
Mostly being a muppet, since you ask.
A muppet? wow. Jim Henson's intellectual property aside, who do you think is doing the controlling? Got a good theory for me?
But everytime someone brings up something on this list that is going to change the response is: NOOOOOOOOOOOOOOOOOOOOOOO IT CANNOT CHANGE. CHANGE IS BAD. DON'T CHANGE THINGS.
That's a very disingenuous misstatement of what people have asked for. A more honest summary would be:
"Don't make this change so hastily -- since we can do this properly in FC5, please let's do it then, when Extras is workable".
That's a very disingenuous statement too. I think extras is workable now. If it's not I wonder what I've been building every night for the past N weeks.
-sv
On Feb 25, 2005, seth vidal skvidal@phy.duke.edu wrote:
I think extras is workable now. If it's not I wonder what I've been building every night for the past N weeks.
I'm sure you'd think it's workable. Let's see:
- you operate one of the biggest mirrors of FC and presumably FE
- even if you didn't have FE locally, you've got a *very* fat network pipe at your disposal
- you're the author of the tool that gives most people easy-ish access to FE
- you run the FE human build system
That's hardly the case for the typical Fedora user. In fact, if I knew there was only one person on Earth (or in the universe!) that was happy about the usability of the current Fedora Extras, my first guess would be you, and the second would probably be Bill Gates :-)
This is not meant as an insult or as criticism; I really appreciate your effort, and thank you for that. I just don't think your situation is anywhere close to that of most of our user base, and as much as you might try to make your views impartial and unaffected by this, it's very likely to still be very biased. Moving useful packages from Fedora Core to Fedora Extras, as it stands, is too hasty a step. We should extend the Fedora Core tools such that the Fedora distribution (by that I wish I could mean Core + Extras) can be installed and used as such, no matter how fat their network pipe is.
I'm sure you'd think it's workable. Let's see:
you operate one of the biggest mirrors of FC and presumably FE
even if you didn't have FE locally, you've got a *very* fat
network pipe at your disposal
- you're the author of the tool that gives most people easy-ish access
to FE
- you run the FE human build system
I also admin and provide the machine that is fedoraproject.org. I set up the wiki, I wrote the scripts to provide the rss feeds of the packages recently updated. Let's see, what else. Hmm, I host and provide the machine that is download.fedoralegacy.org. I do many of these things b/c of the opportunities my employer gives me by being a reasonably good-sized university.
What do the things I try to contribute have to do with my belief that extras functions? You maintain libtool and a number of compiler-related functions. Does this mean you are not to be trusted about the state of the compilers?
I believe extras functions b/c they are are over 901 packages in extras. There are a whole bunch of people packaging for it now. My role is just to rebuild these things while we work on the build system automation.
That's hardly the case for the typical Fedora user. In fact, if I knew there was only one person on Earth (or in the universe!) that was happy about the usability of the current Fedora Extras, my first guess would be you, and the second would probably be Bill Gates :-)
This is just bizarre.
This is not meant as an insult or as criticism; I really appreciate your effort, and thank you for that. I just don't think your situation is anywhere close to that of most of our user base, and as much as you might try to make your views impartial and unaffected by this, it's very likely to still be very biased. Moving useful packages from Fedora Core to Fedora Extras, as it stands, is too hasty a step. We should extend the Fedora Core tools such that the Fedora distribution (by that I wish I could mean Core + Extras) can be installed and used as such, no matter how fat their network pipe is.
So here's the problem, you're missing. Let's give you the example of the user not having a fast network connection.
cases: 1. the distro is 5 isos - they spend 8 yrs downloading 5 isos to install about 30% of the packages available on them - they've wasted a lot of time and probably made a number of coasters in the process.
2. the distro is 4 isos - they spend 6 yrs download 4 isos to install about 30% of the packages available on them. Then finding that their FAVORITE package is not there they spend 1 yr downloading only the packages they want from extras.
So if we're worried about users with limited bandwidth then we would want the latter. Which means putting fewer packages in core.
3. the distro is 4 or 5 isos - the user is given the cds from a friend with a faster network connection. The user consumes no bandwidth at all, so far. a. it's 5 isos - their FAVORITE package is there so they're done (until they see something cool they want in extras, of course) b. it's 4 isos their FAVORITE package is not there - so they ask the friend to burn them a cd of a chunk of things from extras. Heck, if the friend is really nice s/he can get a list of what they need, run repoclosure on it across base + extras and then run createrepo on the cd before handing it over. Then s/he knows that the user has all they need. The user pops in the cd, runs and adds a repo to their yum.repos.d and they're cooking with gas.
4. the distro is 4 or 5 isos - the user is given the cds but not from a friend and has no other way than a 28.8K modem to download the rest. a. the distro is 4 isos - they don't have their FAVORITE package but then again they don't have the ability to play ascii art video files either. They don't have lots of things. I'm sorry, but hey, maybe someone wants to make isos of Extras like the user with the friend in the case above. b. the distro is 5 isos - they have their FAVORITE package, but they still can't play ascii art video files. So maybe someone volunteering to look at isos of extras is the right solution.
hey, wait a second. You're a programmer aren't you? would you like to contribute to fedora extras? I bet you could come up with a way to make isos from Fedora Extras!
That's fantastic, thanks for volunteering instead of just being another complaining voice w/o a solution.
-sv
On Feb 26, 2005, seth vidal skvidal@phy.duke.edu wrote:
What do the things I try to contribute have to do with my belief that extras functions? You maintain libtool and a number of compiler-related functions. Does this mean you are not to be trusted about the state of the compilers?
No, it means that if people moved features out of say the kernel claiming they could be implemented by the compiler or glibc, I wouldn't feel as uncomfortable because I could implement them myself if I had the time and inclination to do so. I'm at an advantage position in this regard. Just like you're at an advantage position WRT Fedora Extras.
I believe extras functions b/c they are are over 901 packages in extras.
See, the problem is not in extras. It works perfectly well, and there's very little to improve other than the creation of ISOs at about the same time as the release.
The problem is in Core, that's missing essential features to make Extras a seamless part of the distro. Such features are scheduled to FC5, but nevertheless we're pushing useful packages from Core to Extras as if this would have no impact on anyone. As if the seamless integration was already in place. This is the mistake I'm disputing. My solution is to just bring the packages that were removed out of the madness to shrink the Core to an arbitrary limit. It's not shrinking the distro (Core + Extras), just pushing bits around, making some of them less convenient to get to.
Sure having CDs of Extras available for download would address part of the problem: people would still be able to ask friends with big pipes to download and burn CDs for them. But how convenient is the experience of installing packages from such CDs be? Anaconda won't be able to install packages from such CDs; will system-config-packages? How about yum, will it require messing with yum config files, or does it have magic to resolve deps and install packages from a collection of CDs that have dep closure as a whole, but not individually? (i.e., I want to install package foo that's in CD2, but that depends on bar that's in CD1)
That's hardly the case for the typical Fedora user. In fact, if I knew there was only one person on Earth (or in the universe!) that was happy about the usability of the current Fedora Extras, my first guess would be you, and the second would probably be Bill Gates :-)
This is just bizarre.
In case the point of the joke was not clear, I think this rush to move packages out of the Core before the Core is ready for Extras will make Fedora as a whole worse, and anything that makes a GNU/Linux distro probably makes Bill Gates a richer man.
- the distro is 5 isos - they spend 8 yrs downloading 5 isos to install
about 30% of the packages available on them
- they've wasted a lot of time and probably made a number of coasters
in the process.
Just because I'm a pedant, make that 4.5 isos, which was the original space figure we had. You don't have to download the second half of the last CD, so what we're saving is not 2 years of download (heh :-), just half a year or so.
So if we're worried about users with limited bandwidth then we would want the latter. Which means putting fewer packages in core.
Sure. As soon as the Core is ready.
Besides, there's always the option of downloading the individual packages, or perform an HTTP install using a local web proxy. If you don't have a lot of bandwidth but can wait for 5 years for the install to complete, that's probably the way to go. For such users, whether something is in Core or Extras makes little difference, except for updates possibly breaking working packages.
b. it's 4 isos their FAVORITE package is not there - so they ask the friend to burn them a cd of a chunk of things from extras. Heck, if the friend is really nice s/he can get a list of what they need, run repoclosure on it across base + extras and then run createrepo on the cd before handing it over. Then s/he knows that the user has all they need. The user pops in the cd, runs and adds a repo to their yum.repos.d and they're cooking with gas.
If it fits in a single CD, or each CD is made repo-closed, yes.
either. They don't have lots of things. I'm sorry, but hey, maybe someone wants to make isos of Extras like the user with the friend in the case above.
They can't. And nobody can, if I'm reading the Fedora trademark guidelines. Yeah, we should fix that.
But fine, someone could burn select rpms into CDs for friends. But companies can't create Extras CDs fitting certain profiles and sell them, or distribute them with magazines, using the Fedora name.
b. the distro is 5 isos - they have their FAVORITE package, but they still can't play ascii art video files. So maybe someone volunteering to look at isos of extras is the right solution.
It would help, but as I explained above, we still need better tools.
hey, wait a second. You're a programmer aren't you?
Allegedly :-)
would you like to contribute to fedora extras? I bet you could come up with a way to make isos from Fedora Extras!
Hey, I know we have some Python scripts to create the Core CDs! Why couldn't we just tell it to take packages from the Extras pool as well, and roll a single set of CDs? Wouldn't that be cool? :-)
That's fantastic, thanks for volunteering instead of just being another complaining voice w/o a solution.
The solution that many of us have been proposing is to revert the not-well-thought-out rush to shrink Core before the tools are ready to make Extras a seamless part of the distro.
On Sat, 2005-02-26 at 04:22 -0300, Alexandre Oliva wrote:
On Feb 26, 2005, seth vidal skvidal@phy.duke.edu wrote:
I believe extras functions b/c they are are over 901 packages in extras.
[snip]
Sure having CDs of Extras available for download would address part of the problem: people would still be able to ask friends with big pipes to download and burn CDs for them. But how convenient is the experience of installing packages from such CDs be? Anaconda won't be able to install packages from such CDs; will system-config-packages?
Yes. And firstboot even asks for such CDs. And has since before Fedora existed :)
Jeremy
On Feb 27, 2005, Jeremy Katz katzj@redhat.com wrote:
On Sat, 2005-02-26 at 04:22 -0300, Alexandre Oliva wrote:
On Feb 26, 2005, seth vidal skvidal@phy.duke.edu wrote:
I believe extras functions b/c they are are over 901 packages in extras.
[snip]
Sure having CDs of Extras available for download would address part of the problem: people would still be able to ask friends with big pipes to download and burn CDs for them. But how convenient is the experience of installing packages from such CDs be? Anaconda won't be able to install packages from such CDs; will system-config-packages?
Yes. And firstboot even asks for such CDs. And has since before Fedora existed :)
Yeah, I know. But firstboot doesn't run for kickstart installs, for one, and kickstart can't use Extras CDs, so you're stuck with doing the post-install stage by hand. Yuck.
Also, see the other points about making the CDs available in a form that won't get users in dependency hell.
What if I want to install a package from an Extras CD that depends on a Core package that I didn't install? Will it let me know which Core CD contains it?
Alexandre Oliva wrote:
Yeah, I know. But firstboot doesn't run for kickstart installs, for one, and kickstart can't use Extras CDs, so you're stuck with doing the post-install stage by hand. Yuck.
1) You can configure firstboot to run after kickstarting "firstboot --enable" in your kickstart file.
2) Do what I do. Kickstart %post section that installs a rpm with updates fot yum repos as well as new ones. I import all the necessary keys and do a "yum -y update" and then "yum -y install packagename". This way when the computer reboots you have an up-to-date system. I use this process to add my own custom repo and I have a rpm for "desktop" systems whose dependancies are the software I want installed.
Cheers,
On Mon, 2005-02-28 at 16:51 -0500, Eric Warnke wrote:
Alexandre Oliva wrote:
Yeah, I know. But firstboot doesn't run for kickstart installs, for one, and kickstart can't use Extras CDs, so you're stuck with doing the post-install stage by hand. Yuck.
- You can configure firstboot to run after kickstarting "firstboot
--enable" in your kickstart file.
- Do what I do. Kickstart %post section that installs a rpm with
updates fot yum repos as well as new ones. I import all the necessary keys and do a "yum -y update" and then "yum -y install packagename". This way when the computer reboots you have an up-to-date system. I use this process to add my own custom repo and I have a rpm for "desktop" systems whose dependancies are the software I want installed.
yum in fc4 should allow:
yum -y shell /path/to/some/file
file would contain:
install foo remove bar update baz groupinstall foo run
it works in yum 2.3.0 now, iirc, but it's not as refined as i'd like.
-sv
On Feb 28, 2005, Eric Warnke eric@snowmoon.com wrote:
- Do what I do. Kickstart %post section that installs a rpm with
updates fot yum repos as well as new ones. I import all the necessary keys and do a "yum -y update" and then "yum -y install packagename".
Yeah, I had something like that at some point. selinux attributes are somewhat messed up when you do this. At least they still are for the configuration stuff I run in %post, that among other things runs texhash, and tex config files get incorrectly-labeled. Perhaps it's unrelated and I'm just barking up the wrong tree, but I was concerned it could mess things up further and didn't try that again.
On Mon, 2005-02-28 at 23:15 -0300, Alexandre Oliva wrote:
On Feb 28, 2005, Eric Warnke eric@snowmoon.com wrote:
- Do what I do. Kickstart %post section that installs a rpm with
updates fot yum repos as well as new ones. I import all the necessary keys and do a "yum -y update" and then "yum -y install packagename".
Yeah, I had something like that at some point. selinux attributes are somewhat messed up when you do this. At least they still are for the configuration stuff I run in %post, that among other things runs texhash, and tex config files get incorrectly-labeled. Perhaps it's unrelated and I'm just barking up the wrong tree, but I was concerned it could mess things up further and didn't try that again.
selinux attributes should not be messed up by installing another package in %post from the distro. if you have a file that has the wrong attributes that came from a package file a bug against that package.
-sv
On Mon, 2005-02-28 at 23:15 -0300, Alexandre Oliva wrote:
On Feb 28, 2005, Eric Warnke eric@snowmoon.com wrote:
- Do what I do. Kickstart %post section that installs a rpm with
updates fot yum repos as well as new ones. I import all the necessary keys and do a "yum -y update" and then "yum -y install packagename".
Yeah, I had something like that at some point. selinux attributes are somewhat messed up when you do this. At least they still are for the configuration stuff I run in %post, that among other things runs texhash, and tex config files get incorrectly-labeled.
Can you elaborate a bit? Is this really just doing:
yum install blah
in the %post section? Or are you also passing options like --root or whatever to RPM?
We do have a longstanding TODO now to fix up the RPM security context initialization to use the libselinux functionality instead of its own version; it might solve this issue.
On Mar 1, 2005, Colin Walters walters@redhat.com wrote:
On Mon, 2005-02-28 at 23:15 -0300, Alexandre Oliva wrote:
On Feb 28, 2005, Eric Warnke eric@snowmoon.com wrote:
- Do what I do. Kickstart %post section that installs a rpm with
updates fot yum repos as well as new ones. I import all the necessary keys and do a "yum -y update" and then "yum -y install packagename".
Yeah, I had something like that at some point. selinux attributes are somewhat messed up when you do this. At least they still are for the configuration stuff I run in %post, that among other things runs texhash, and tex config files get incorrectly-labeled.
Can you elaborate a bit? Is this really just doing:
yum install blah
Nope, it's not actually doing any of that. What it's doing now is running a script that contains:
grep ['^portuges[ ]'] \ /usr/share/texmf/tex/generic/config/language.dat > /dev/null || VISUAL="emacs -batch -nw -l `pwd`/latex-hyphen.el" \ texconfig hyphen latex
egrep \ ['^@ [a-zA-Z0-9][a-zA-Z0-9]* [0-9][0-9.]*(in|mm) [0-9][0-9.]*(in|mm)$'] \ /usr/share/texmf/dvips/config/config.ps | sed 1q | grep letter > /dev/null || texconfig dvips paper letter
grep '^o$' /usr/share/texmf/dvips/config/config.ps > /dev/null || texconfig dvips printcmd -
latex-hyphen.el follows:
(progn (find-file (car command-line-args-left)) (replace-regexp "^%!* *portuges" "portuges") (save-buffer 0) (save-buffers-kill-emacs))
After running the above during %post, most of the tex config files will have incorrect labels, that a post-reboot fixfiles run will fix.
I also run stuff such as:
gpg --import $keyfile gpg --import `/usr/sbin/up2date --gpg-flags` $keyfile rpm --import $keyfile
in %post, for a number of ${keyfile}s, and, in a fresh install, the newly-created files /root/.gnupg will be mislabeled too.
On Sat, 2005-02-26 at 01:39 -0500, seth vidal wrote:
hey, wait a second. You're a programmer aren't you? would you like to contribute to fedora extras? I bet you could come up with a way to make isos from Fedora Extras!
Making ISOs from Extras isn't hard, and isn't the problem. Please do try to keep up with the conversation.
The problem is not just that there are no ISOs of Extras yet -- the problem is that that anaconda won't handle external repositories until FC5, whether you can get them onto an ISO or not.
That's fantastic, thanks for volunteering instead of just being another complaining voice w/o a solution.
You're being deliberately misleading again. Alex offered his preferred solution on fedora-maintainers list, and isn't 'just complaining'. Look for Message-ID orpsyoqueb.fsf@livre.redhat.lsd.ic.unicamp.br
I fully support Fedora Extras. I've set up a build box for Extras on FC3/PPC and have made a yum repository available. I'm currently trying to work out where to find a spare build box (or enough disk space for a buildroot) for the FC4 version. I'll make ISOs for it when anaconda can handle them too. But that's not the stumbling block.
Extras is good -- but it's not workable _yet_ as a mechanism for dumping packages from Core. Packages we dump now, we have to accept that they _are_ being dumped, just like the packages which were dumped for FC2. We can't excuse it on the basis that "Extras will pick them up". That doesn't work until FC5.
On Feb 25, 2005, seth vidal skvidal@phy.duke.edu wrote:
why do you think fedora-maintainers is closed to posts from non-maintainers?
Because someone wasn't in their right mind when this idea came up?
On Fri, 2005-02-25 at 16:57 -0300, Alexandre Oliva wrote:
On Feb 25, 2005, seth vidal skvidal@phy.duke.edu wrote:
why do you think fedora-maintainers is closed to posts from non-maintainers?
Because someone wasn't in their right mind when this idea came up?
it was decided by a group of red hat and non red hat fedora contributors at the pre-fudcon meetings.
Mostly to keep the signal/noise ratio down.
As you can see by this weeks output on f-d-l it's hard to get very far with everyone posting even if they don't have much of a dog in the fight.
-sv
seth vidal wrote:
Mostly to keep the signal/noise ratio down.
Sounds awful elitist and Machiavellian for a community driven project.
As you can see by this weeks output on f-d-l it's hard to get very far with everyone posting even if they don't have much of a dog in the fight.
I agree, but then you are just granting the illusion of a community controlled project arent you? Essentially the real discussion concerning dev will have been moved to f-m right? I understand that trying to keep the project moving without all of this "change is bad" and "me too" crap is important but i think that this "fix" fails to live up to the community aspect of the project doesnt it? Essentially your voice doesnt matter if you arent a maintainer anymore because the other lists will be read less and less by RH and maintainers over time. As a result you will lose the community driven nature i think because all of the opinions batted about will be those of maintainers alone. A moderated white list of users that conduct themselves in a prescribed manner makes most sense to me. -mf
Michael Favia wrote:
I agree, but then you are just granting the illusion of a community controlled project arent you?
Please replace "controlled" with "driven". i have no illusions of grandure for the community place nor do i think it is desirable. :). -mf
On Fri, 25 Feb 2005, Michael Favia wrote:
Michael Favia wrote:
I agree, but then you are just granting the illusion of a community controlled project arent you?
Please replace "controlled" with "driven". i have no illusions of grandure for the community place nor do i think it is desirable. :). -mf
May I remind you of the Fedora "contract"
http://fedora.redhat.com/about/objectives.html
Specifically I think this discussion touches on points 1, 6, 7, and 12.
Cheers, Eric Warnke Systems Administrator - Research Technology SUNY at Albany
On Fri, 2005-02-25 at 14:49 -0600, Michael Favia wrote:
seth vidal wrote:
Mostly to keep the signal/noise ratio down.
Sounds awful elitist and Machiavellian for a community driven project.
It does? Who do I represent? I think I am a member of 'the community'? I think Jeremy and Bill and Elliot are too. I think they're members of the contributing community. It's not elitistism it's based on listening to the people who are doing the work. In large projects if you listen to everyone you can never get any work done. So you listen to the people are contributing. I don't think that's particularly crazy. Show me an open source project that is NOT like that. This is not a democracy - I hope it's a meritocracy - but in reality it's something more like 'those people who do the work get listened to'-ocracy.
Do the work, see how many people listen. They may not agree - but they'll listen.
I agree, but then you are just granting the illusion of a community controlled project arent you? Essentially the real discussion concerning dev will have been moved to f-m right? I understand that trying to keep the project moving without all of this "change is bad" and "me too" crap is important but i think that this "fix" fails to live up to the community aspect of the project doesnt it? Essentially your voice doesnt matter if you arent a maintainer anymore because the other lists will be read less and less by RH and maintainers over time. As a result you will lose the community driven nature i think because all of the opinions batted about will be those of maintainers alone. A moderated white list of users that conduct themselves in a prescribed manner makes most sense to me.
Then tell me how else you do it? How to cull the signal from the noise?
show me a better way and we'll get there lickety-damn-split.
-sv
Then tell me how else you do it? How to cull the signal from the noise?
show me a better way and we'll get there lickety-damn-split.
one more addendum - just b/c discussion about decisions in the distro and extras should go to fedora-maintainers doesn't mean I'll stop reading fedora-devel. Hopefully it will mean fedora-devel will become more useful.
-sv
On Fri, 2005-02-25 at 16:08 -0500, seth vidal wrote:
Then tell me how else you do it? How to cull the signal from the noise?
show me a better way and we'll get there lickety-damn-split.
one more addendum - just b/c discussion about decisions in the distro and extras should go to fedora-maintainers doesn't mean I'll stop reading fedora-devel. Hopefully it will mean fedora-devel will become more useful.
Moving packages between Core and Extras is Fedora development.
Moving discussions to a closed list, means nothing but you are not willing to listen to other opinions and prefer to decide and proceed at your own will - A severe fault, IMNSHO.
Ralf
Moving packages between Core and Extras is Fedora development.
Moving discussions to a closed list, means nothing but you are not willing to listen to other opinions and prefer to decide and proceed at your own will - A severe fault, IMNSHO.
No, it just means I don't have time to listen to the opinions of folks who aren't putting in some effort to contribute. I'll take the time to listen if you're contributing and trying to be constructive.
-sv
On Sun, February 27, 2005 4:25 am, seth vidal said:
No, it just means I don't have time to listen to the opinions of folks who aren't putting in some effort to contribute. I'll take the time to listen if you're contributing and trying to be constructive.
Hey Seth,
Not every issue is a matter of opinion, and keeping the list open to the widest number of contributors should be a net win. Even the annoying package removal thread wasn't that hard to skim through. Seems like a small price to pay to keep from cutting yourself off from useful posts (ie. constructive contributions).
Sean
On Sun, 2005-02-27 at 07:31 -0500, Sean wrote:
Not every issue is a matter of opinion, and keeping the list open to the widest number of contributors should be a net win. Even the annoying package removal thread wasn't that hard to skim through. Seems like a small price to pay to keep from cutting yourself off from useful posts (ie. constructive contributions).
why do you think I'd be cut off from the contributions? I'm not stopping reading fedora-devel, but for some issues I wouldn't post there.
Seriously, though it doesn't cut me off from most contributions and b/c of the structure of maintainers list it lends itself nicely to people who are willing to do more than just give their opinion actually discussing items.
Over the years of working on misc open source projects I realized I get a more tired, more quickly of hearing complaints and opinions from people if they're not willing to help either solve them or implement their solutions.
that's just me though. -sv
On Sun, February 27, 2005 11:42 am, seth vidal said:
Over the years of working on misc open source projects I realized I get a more tired, more quickly of hearing complaints and opinions from people if they're not willing to help either solve them or implement their solutions.
that's just me though.
Naw it's not just you; who wants to listen to complainers? Guess the only point was that not _everyone_ who is a first time poster is just a complainer, and may actually have a valuable contribution. It's these people you'll cut yourself off from because of the other noise makers.
The argument comes down to how much noise you're willing to endure in order to leave the door open for valuable posts from people who are too new to have made acknowledged contributions. A moderated list might be a better compromise.
Sean
Naw it's not just you; who wants to listen to complainers? Guess the only point was that not _everyone_ who is a first time poster is just a complainer, and may actually have a valuable contribution. It's these people you'll cut yourself off from because of the other noise makers.
The argument comes down to how much noise you're willing to endure in order to leave the door open for valuable posts from people who are too new to have made acknowledged contributions. A moderated list might be a better compromise.
a moderated list requires a moderator. And a list with the type of traffic fedora-devel has would need a moderator with no life.
-sv
The argument comes down to how much noise you're willing to endure in order to leave the door open for valuable posts from people who are too new to have made acknowledged contributions. A moderated list might be a better compromise.
Why don't we see how this new system all works out? The original approach with fedora-devel-list has been around for awhile, and there have been problems with S/N.
So let's give this new system some time and see what the risk/reward is to this approach. After all, even though Fedora as an OS might have a long lineage, Fedora as a community is still really new. This makes everything both easy and hard because there's a lot of users to begin with, and everyone wants almost-the-same-thing-but-not-quite. So, figuring out how to build a community on the fly that works for everyone is a hard problem. Having some data or experience with which to support a particular point of view will help.
If there are significant downsides to the new structure, or things become unworkable, I'm sure that the Fedora folks will be open to revisiting the issue.
Richard
PS I am not on fedora-maintainers.
seth vidal wrote:
It does? Who do I represent? I think I am a member of 'the community'? I think Jeremy and Bill and Elliot are too. I think they're members of the contributing community.
Agreed.
It's not elitistism it's based on listening to the people who are doing the work. In large projects if you listen to everyone you can never get any work done. So you listen to the people are contributing. I don't think that's particularly crazy. Show me an open source project that is NOT like that. This is not a democracy - I hope it's a meritocracy - but in reality it's something more like 'those people who do the work get listened to'-ocracy.
I feel this model assumes that maintainership is the only meritorious activity in fedora. I think that other meritorious activities such as useful analysis of plans and the occasional proposal of alternative solutions also is meritorious. Im not talking about backseat coding here but rather offering an alternative perspective to create a well-rounded view of the goal and the bumps in the path to get there as well as some suggestions to traverse the trail efficiently. If it is the position of redhat that this isnt the case i understand but i think it is a mistake to limit input to that one group.
Then tell me how else you do it? How to cull the signal from the noise?
show me a better way and we'll get there lickety-damn-split.
My best suggestion is to open the "new dev list" (aka maintainers) to people that serve other valuable roles or who routinely inject intelligent ideas into conversation on fedora-devel. Essentially i like the idea of a moderated list because i grow weary of a thread with 512 msgs (slimfast slimfest) because it takes half my morning to weed through it and very few users read it and end up asking the same questions elsewhere in the list.
My only argument is that i think that people provide value in other ways than simply maintainership. Admit users to the list contingent on their behavior and ability to keep "noises off". If you find they are habitual flamers and dont contribute enough to justify the noise warn them, if it doesnt improve then thank them for the input and show them the door politely. If you start small with the whitelist and add users slowly it will be easy to manage and should maintain equilibrium without much influence. not to mention improve the level of decorum with which users treat each other on a smaller list with more accountability.
I think we should be honest and mention that it is unlikely that the devel list will maintain the same level of importance with the introduction of a new "working list". I dont fault anyone for this but there are only so many hours in the day and the S:N ratio will be so much lower on devel when everyone bails to maintainer that it will increasingly become more like "fedora-list" and justifiably less worth reading. I read lists in order of importance (based on time constraints) and fedora devel will drop way lower with the advent of maintainers. -mf
I feel this model assumes that maintainership is the only meritorious activity in fedora. I think that other meritorious activities such as useful analysis of plans and the occasional proposal of alternative solutions also is meritorious. Im not talking about backseat coding here but rather offering an alternative perspective to create a well-rounded view of the goal and the bumps in the path to get there as well as some suggestions to traverse the trail efficiently. If it is the position of redhat that this isnt the case i understand but i think it is a mistake to limit input to that one group.
No, in fact, quite the contrary. We already raised this issue people can recommend/sponsor other non-packagers for inclusion on that list. I fully realize there are lots of non-packging meritous contributions to fedora.
My best suggestion is to open the "new dev list" (aka maintainers) to people that serve other valuable roles or who routinely inject intelligent ideas into conversation on fedora-devel. Essentially i like the idea of a moderated list because i grow weary of a thread with 512 msgs (slimfast slimfest) because it takes half my morning to weed through it and very few users read it and end up asking the same questions elsewhere in the list.
And I read every post on the thread. Sad huh? :) But if you want to help in that way then read through every message and work with Colin Charles on reviving the Fedora News Updates. And guess what- that also means you're contributing usefully.
I really don't think it is inappropriate to try to get folks to contribute in order to be able to be more involved in the decision making process.
-sv
On Fri, 2005-02-25 at 14:49 -0600, Michael Favia wrote:
Mostly to keep the signal/noise ratio down.
Sounds awful elitist and Machiavellian for a community driven project.
All major open source projects have closed lists to keep the s/n ratio down for other development discussions. We're following the model GNOME used for gnome-hackers and gnome-hackers-readonly
(though they then made the mistake of desktop-devel-list which became rather noisy, again)
I agree, but then you are just granting the illusion of a community controlled project arent you? Essentially the real discussion concerning dev will have been moved to f-m right? I understand that trying to keep
No. If a community member not on fedora-maintainers reads something in fedora-maintainers-readonly, I'm sure the thread can be continued on in fedora-devel-list
the project moving without all of this "change is bad" and "me too" crap is important but i think that this "fix" fails to live up to the community aspect of the project doesnt it? Essentially your voice doesnt matter if you arent a maintainer anymore because the other lists will be read less and less by RH and maintainers over time. As a result you will lose the community driven nature i think because all of the opinions batted about will be those of maintainers alone. A moderated white list of users that conduct themselves in a prescribed manner makes most sense to me.
No. Folk will still read fedora-devel, and don't feel left out by it
Also, the other thing to keep in mind is that getting a package maintained isn't too hard, and the Extras process is now, open. My last cvs sync gave me about 572 packages in Extras; last time I checked with the "universe" of packages that another major distribution had, they fit an entire 2 DVDs iirc. So contribute more packages, I guess, and lets make Fedora rock (harder)!
On Fri, February 25, 2005 11:43 pm, Colin Charles said:
Hey colin,
All major open source projects have closed lists to keep the s/n ratio down for other development discussions. We're following the model GNOME used for gnome-hackers and gnome-hackers-readonly
This is a little bit of an exaggeration; several prominent open source projects do not have a closed list.
(though they then made the mistake of desktop-devel-list which became rather noisy, again)
Noise may be a fair tradeoff if opening things up also leads to additional valuable input.
No. If a community member not on fedora-maintainers reads something in fedora-maintainers-readonly, I'm sure the thread can be continued on in fedora-devel-list
Not if you want the readonly list membership to see it. And if they have to read the devel-list too, you haven't accomplished anything.
No. Folk will still read fedora-devel, and don't feel left out by it
Who are you speaking for, and how do you know? Certainly people who don't often contribute may well have a valuable insight that will be harder to share. Such a person is bound to feel left out.
Also, the other thing to keep in mind is that getting a package maintained isn't too hard, and the Extras process is now, open. My last cvs sync gave me about 572 packages in Extras; last time I checked with the "universe" of packages that another major distribution had, they fit an entire 2 DVDs iirc. So contribute more packages, I guess, and lets make Fedora rock (harder)!
I don't see what this has to do with keeping the lists open to contributions from those who might not have contributed before. The people who believe Fedora is better served by avoiding closed lists want to improve Fedora just as much.
Cheers, Sean
On Fri, 25 Feb 2005, seth vidal wrote:
why do you think fedora-maintainers is closed to posts from non-maintainers?
it was decided by a group of red hat and non red hat fedora contributors at the pre-fudcon meetings. Mostly to keep the signal/noise ratio down.
Yeah, backroom deals keep the riff-raff out and the surprise in a relationship, all right. And the trains all run on time. It is just has little to do a democratic process.
George Orwell had this one called: The only Community in Fedora is for those pigs who are more equal than others. It is rank hypocrisy to proclaim oneself a community, when power and privilege of insider status are reserved to a small elite.
-- Russ Herrold
On Sun, 2005-02-27 at 01:48 -0500, R P Herrold wrote:
On Fri, 25 Feb 2005, seth vidal wrote:
why do you think fedora-maintainers is closed to posts from non-maintainers?
it was decided by a group of red hat and non red hat fedora contributors at the pre-fudcon meetings. Mostly to keep the signal/noise ratio down.
Yeah, backroom deals keep the riff-raff out and the surprise in a relationship, all right. And the trains all run on time. It is just has little to do a democratic process.
George Orwell had this one called: The only Community in Fedora is for those pigs who are more equal than others. It is rank hypocrisy to proclaim oneself a community, when power and privilege of insider status are reserved to a small elite.
*yawn*
Russ you of all people should know that there's no benefit to asking everyone for their opinion. It just gives you a lot of opinions, someone still has to make the decisions.
Why is there a private caos-steering-committee, russ? Are you hiding something? Is it hyprocrisy!?!!
no, it's not, it's just so we(I'm on it, remember?:) can talk about things w/o worrying too much. How did people get on the steering committee? Greg Asked us. No elections, it was based on people who had done the work and helped out.
No democracy there.
There's no democracy in the people who lead ubuntu either. nor in suse/novell nor in slackware gnome has board elections - but the people who are in control over gnome is not the board the people in control of gnome work for novell and red hat.
postfix is controlled completely by Wietse Venema sendmail by sendmail co and eric allman
apache by the apache foundation whose membership is based on what? Their contributions to the project, not on elections.
bind - entirely isc.
The kernel summit is invite only.
Open source is not about democracy. It's never been about democracy. It is about social mobility w/i any organization. The ability to move up (or down) in the social stratum.
You move up in terms of control and responsibility by doing the work. By contributing. If you do not contribute, you don't get any decision-making authority.
I will say this once again and for all, if anyone wants to find themselves taking more responsibility in fedora ALL THEY HAVE TO DO IS TO DO THE WORK.
DO NOT WAIT. Do the work.
If you need help knowing what needs to be worked on. ASK.
-sv
On Sun, Feb 27, 2005 at 02:09:44AM -0500, seth vidal wrote:
I will say this once again and for all, if anyone wants to find themselves taking more responsibility in fedora ALL THEY HAVE TO DO IS TO DO THE WORK.
Very valid points. However - things are not black and white - read LKML - Linus listens - even to non kernel hackers - it is one of his many remarkable strengths.
g/
On Sun, 2005-02-27 at 10:33 -0500, Mail Lists wrote:
On Sun, Feb 27, 2005 at 02:09:44AM -0500, seth vidal wrote:
I will say this once again and for all, if anyone wants to find themselves taking more responsibility in fedora ALL THEY HAVE TO DO IS TO DO THE WORK.
Very valid points. However - things are not black and white - read LKML - Linus listens - even to non kernel hackers - it is one of his many remarkable strengths.
and where have we implied that users won't be listened to? But as it is if you want to listen to users on fedora-list and everyone else on fedora-devel-list it is a full time job JUST to read the email.
-sv
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of seth vidal Sent: Sunday, February 27, 2005 10:44 AM To: Development discussions related to Fedora Core Subject: Re: [fedora-d-rh] Re: FC3 -> FC4 Upgrade? (was Re: reducingdistribution CD count)
On Sun, 2005-02-27 at 10:33 -0500, Mail Lists wrote:
On Sun, Feb 27, 2005 at 02:09:44AM -0500, seth vidal wrote:
I will say this once again and for all, if anyone wants to find themselves taking more responsibility in fedora ALL THEY HAVE TO DO IS TO DO THE WORK.
Very valid points. However - things are not black and white - read LKML - Linus listens - even to non kernel hackers - it is one of his many remarkable strengths.
and where have we implied that users won't be listened to? But as it is if you want to listen to users on fedora-list and everyone else on fedora-devel-list it is a full time job JUST to read the email.
-sv
I agree, but you have to listen to all of the complainers as well as contributors b/c quite often the new ideas come from the complainers rather than the contributors, cause generally developers are very happy with the status quo. No complaints means everything is okay and no need to develop or create new things. My problem is that everything is argued, some things should be allowed to die in the wind, they just aren't worth the effort to respond to. i.e. insulting someone for their ignorance of a topic or trivial suggestion, these things should just be allowed to die and push the good complaints or the good ideas and treat everything else as a quirk of nature. That would probably make these threads a hell of a lot shorter.
George Orwell had this one called: The only Community in
And with the Godwinization, the cycle of life is complete.
On Fri, Feb 25, 2005 at 01:08:29PM -0600, Chris Adams wrote:
And as I've said, it didn't on such a large scale to things lots of people still used regularly.
Plus, most of the time they were marked as obsolete/deprecated one or two releases before the actual removal.
So much for Fedora being an "open" project.
This is mostly going to give fodder to critics. If it is indeed the plan to basically ignore any of the consequences of the "mass Core eviction", I'd suggest littering the release notes, the installer and the first boot with warnings about the problems that might arise and the proper way to address them. They need to be in big, flashing, red letters. FC3 release notes covered the subject, but people are still inquiring about the kernel-source package.
On Ven 25 février 2005 16:56, David Woodhouse a écrit :
On Fri, 2005-02-25 at 10:52 -0500, seth vidal wrote:
So the way I see it here are the items needed to make extras work for fc4:
- branch fc3 off of devel in extras cvs
- get release updates in extras cvs spec files
- build world
- look for things that break
- wash, rinse, repeat.
- Add support to anaconda for multiple repositories (planned for FC5)
What we don't need right now is a lot of fatalism.
What we need is to do it in a controlled fashion; not just dump random packages when a release is imminent. Doing it in rawhide just after the release of FC4 would make sense, and then it will be fine in FC5.
If there was an extra branch synched with rawhide and if all the packages dumped from rawhide these past days were to appear there at lot of people would feel less nervous.
It's not as if these packages need special work - they were already working in rawhide before.
FC3 extras are more difficult - they never were synched with devel so all their problems will need to be fixed at once (which also means it might be a good idea to keep and extra devel branch dogfoodable at all times if we even want extras to be released as the same time as FC in the future)
Regards,
David Woodhouse wrote:
On Fri, 2005-02-25 at 10:52 -0500, seth vidal wrote:
So the way I see it here are the items needed to make extras work for fc4:
- branch fc3 off of devel in extras cvs
- get release updates in extras cvs spec files
- build world
- look for things that break
- wash, rinse, repeat.
- Add support to anaconda for multiple repositories (planned for FC5)
What we don't need right now is a lot of fatalism.
What we need is to do it in a controlled fashion; not just dump random packages when a release is imminent. Doing it in rawhide just after the release of FC4 would make sense, and then it will be fine in FC5.
I have to agree that the timing is a little bad, but package were added to rawhide after FC3 release so now that test1 release is coming up things move into perspective.
The packages are being removed. I say lets leave the horror stories until test1 is out there then
4. look for things that break 5. wash, rinse, repeat.
Gene C. (czar@czarc.net) said:
- Lets say something major which a lot of users will want is move out of the
"core core" and into a secondary "repository" which will still be fully maintained by Red Hat employees. No flaming intended, but lets say this is kde and all kde associated applications. Now that would be a big chunk but it would also be something a lot of users would want. What is the current thinking about how this "secondary repository" will be available to the user? Furthermore, this must be done in such a manner that it is obvious that Red Hat is NOT slighting the packages involved.
I don't see the reason why something like this would need to exist. It's almost sounds like a slight against Extras, that people wouldn't want to use it.
What I would expect to happen is subdivsions of Extras into arbitrary groups that could be CD-ified; I don't think this is technically much work.
- There was some mention of RHEL having "extra" packages which are not part
of the RHEL on CDs. How does RHEL handle the extra packages for stand-alone systems?
They're available only in the RHN channel.
Bill
Bill Nottingham wrote:
Gene C. (czar@czarc.net) said:
- Lets say something major which a lot of users will want is move out of the
"core core" and into a secondary "repository" which will still be fully maintained by Red Hat employees. No flaming intended, but lets say this is kde and all kde associated applications. Now that would be a big chunk but it would also be something a lot of users would want. What is the current thinking about how this "secondary repository" will be available to the user? Furthermore, this must be done in such a manner that it is obvious that Red Hat is NOT slighting the packages involved.
I don't see the reason why something like this would need to exist. It's almost sounds like a slight against Extras, that people wouldn't want to use it.
I dont think that it was intended as a slight but rather a response to the general hands off approach [seemingly] surrounding extras. What Gene was getting at i think was that RetHat expressed its desire to drop the aforementioned packages becuase of space limitation on the distribution media not developer maintenance limitations. Perhaps i am misunderstanding both the nature of extras and the intent of the original author but this is the feeling i have from the outside as well. As a result i think he was looking for a safe place for RedHat to continue maintenance of these packages even if they arent distributed by default (for obvious reasons). Is it a misstatement that packages in extras are relinquished to community maintenance? or does redhat continue maintenance as well? -mf
On Thu, 2005-02-24 at 14:25 -0600, Michael Favia wrote:
Is it a misstatement that packages in extras are relinquished to community maintenance?
I think so, yes.
or does redhat continue maintenance as well?
Is there any reason either one couldn't be true? That is, some packages which RH isn't interested in maintaining, but also some that we recognize are worth effort but shouldn't be part of Core?
Peter Jones wrote:
Is there any reason either one couldn't be true? That is, some packages which RH isn't interested in maintaining, but also some that we recognize are worth effort but shouldn't be part of Core?
I agree completely but i have formed the impression [perhaps mistakenly] that packages moved to extras are "orphaned" packages as far as RH is concerned. Or is that just the norm and not the "law"? I think you will allay a great many fears and improve the perception of extras if this is the case and it is communicated to the user/dev base a little better. In case i am completely mistaken is there a reference document that spells out the distinctions and flow of this type of information? I would much rather read up on it than learn bit by bit pestering people over mailing lists. -mf
On Thu, 2005-02-24 at 19:16 -0600, Michael Favia wrote:
Peter Jones wrote:
Is there any reason either one couldn't be true? That is, some packages which RH isn't interested in maintaining, but also some that we recognize are worth effort but shouldn't be part of Core?
I agree completely but i have formed the impression [perhaps mistakenly] that packages moved to extras are "orphaned" packages as far as RH is concerned. Or is that just the norm and not the "law"? I think you will allay a great many fears and improve the perception of extras if this is the case and it is communicated to the user/dev base a little better. In case i am completely mistaken is there a reference document that spells out the distinctions and flow of this type of information? I would much rather read up on it than learn bit by bit pestering people over mailing lists.
I think it's accurate that Red Hat would like to be maintaining fewer packages and focusing more on the basics, but at the same time I don't know why people are so terrified of that. It will probably make both the basics and the non-basics higher quality to do this since there's more focus on each one.
At the same time I doubt the core/extras line will end up being Red Hat maintenance vs. external maintenance. I think we're heading toward some other definition of core vs. extras. My personal preference leans toward saying core is roughly the union of default install classes, but I'm sure others have thought about it more.
Havoc
Havoc Pennington wrote:
I think it's accurate that Red Hat would like to be maintaining fewer packages and focusing more on the basics, but at the same time I don't know why people are so terrified of that. It will probably make both the basics and the non-basics higher quality to do this since there's more focus on each one.
At the same time I doubt the core/extras line will end up being Red Hat maintenance vs. external maintenance. I think we're heading toward some other definition of core vs. extras. My personal preference leans toward saying core is roughly the union of default install classes, but I'm sure others have thought about it more.
I am of the same persuasion. And i agree completely on the simplification of the distro and the focus on fewer "default" packages because it means the half-life of innovation will decrease dramatically with respect to the "normal users experience". I harbor no fears of abondonment and i think others could be placated as well but believe many are complaining because of the dirth of information available on future plans (possibly because they arent known). As we all know uncertainty shakes even steely-eyed missle men hesitent. Many of the political battles (kde/gnome, exim/sendmail, etc) shoudl be put to rest (finally) when this time comes. I think that "core" as a non duplicating set of functionalites is a great idea that decreases the installation media requirement, bandwidth and overall workload per innovative step. The rest can and should be maintained by the community with RH picking up the ball where it is in its best interest (e.g. angel coding, switching or providing compatability). The key to making this work without alienating a contigent userbase will be the simplicity of selecting and installing non-default (core) packages on installation and after the fact (via network and "extras" cd's). Will the slip of test1 have any effect on the possible availability of a multirepo anaconda up to such a task (fully realizing that there are other hurdles like "extras" installation cd creation)?
Assuming the same amount of resources are comitted to the project a slimmer, more agile, faster moving fedora core will be the result of moving in this direction and i for one welcome it. Thanks for the feedback on the earlier post. -michael
I think it's accurate that Red Hat would like to be maintaining fewer packages and focusing more on the basics, but at the same time I don't know why people are so terrified of that. It will probably make both the basics and the non-basics higher quality to do this since there's more focus on each one.
Until infrastructure is in place, development in FC-extras will be slower than in Fedora Core. Maybe the current way to push the FC-extra resolves this, but I fear lots of additional work for package maintainers.
greetings,
Florian La Roche
Le jeudi 24 février 2005 à 09:06 -0500, Gene C. a écrit :
(...) Comments?
Sorry for my English.
Sad news : > On Tue, Feb 22, 2005 at 02:07:26PM -0500, Build System wrote: > python-twisted-1.3.0-3 > ---------------------- > * Mon Feb 21 2005 Jeremy Katz katzj@redhat.com - 1.3.0-3 > - disable the -docs subpackage for now
I read many things about how to reduce CD count. Nothing really "shocking".
But what I *really* don't like is the split of project between FC and FE like exim in FC and exim-doc in FE *only* because exim-doc is "too big". I want exim in FC or in FE and not some parts in FC and other parts in FE.
1- The documentation is *important*. Documenting is not a pleasant job. 2- Red Hat does not provide clear rules to chose which documentation "deserve" to be in FC. 3- The average joe (me) expect to find the documentation in the same place than the program. A program with its documentation is the same whole thing.
If Red Hat state "*all* documentation will be in FE" I'll said "OK, go for it" (this imply to create a lot of prog-doc packages). If someone ask me where is the documentation I will point FE (end of the story). But with this new policy I'll reply with "I don't really know, it's depend on the feeling of Red Hat".
Other point I don't like, Red Hat is introducing the size criteria : - "Sorry, good project but too big".
Until now, Fedora is a meritocracy and not a "weightwatcherscracy".
I know that FC can't provide all softwares around the world. I this case increase the level of admittance and forget the weightwatchers dictatorship.
The big KDE deserve to be in FC (even if I don't use it) but with this new policy you see some people requesting to move KDE to FE. Other want to drop i18n, ... It's bad(tm).
-devel package : 15O Mo Perhaps we can move all development packages and tools to FE. Fedora need clear rules.
On Thu, 24 Feb 2005, [ISO-8859-1] F�liciano Matias wrote:
But what I *really* don't like is the split of project between FC and FE like exim in FC and exim-doc in FE *only* because exim-doc is "too big". I want exim in FC or in FE and not some parts in FC and other parts in FE.
Yea, that split was crack. At this point the plan is to have exim entirely in Extras.
-- Elliot
On Thu, 2005-02-24 at 16:32 -0500, Elliot Lee wrote:
Yea, that split was crack.
Splitting the documentation packages out into a separate SRPM from the Exim binaries makes a lot of sense -- the docs are distributed separately, updated at different times, and built into a separate RPM package which should have been noarch. There is no overlap between them and the Exim dæmon itself. There was never any real reason for them to be inside the main exim SRPM in the first place. The point in fixing that now was to make it easier to drop the docs¹ if it was really necessary to make space, because upgrades won't suffer just due to the docs being older.
At this point the plan is to have exim entirely in Extras.
I thought that _even_ while we thought there was a point to this exercise and we thought we could make FC4/i386 fit in 4 CDs, we had acknowledged that we couldn't drop packages which were in FC3 because that would make upgrades problematic?
On Thu, 24 Feb 2005, David Woodhouse wrote:
On Thu, 2005-02-24 at 16:32 -0500, Elliot Lee wrote:
Yea, that split was crack.
Splitting the documentation packages out into a separate SRPM from the Exim binaries makes a lot of sense -- the docs are distributed separately, updated at different times, and built into a separate RPM package which should have been noarch. There is no overlap between them and the Exim dæmon itself. There was never any real reason for them to be inside the main exim SRPM in the first place. The point in fixing that now was to make it easier to drop the docs¹ if it was really necessary to make space, because upgrades won't suffer just due to the docs being older.
Yea, the split was not crack.
;-)
-- Elliot
Le jeudi 24 février 2005 à 21:42 +0000, David Woodhouse a écrit :
On Thu, 2005-02-24 at 16:32 -0500, Elliot Lee wrote:
Yea, that split was crack.
Splitting the documentation packages out into a separate SRPM from the Exim binaries makes a lot of sense
I was not talking about this split (sub-package or multi SRPM, ...) but about FC/FE split.
Filiciano Matias wrote:
3- The average joe (me) expect to find the documentation in the same place than the program. A program with its documentation is the same whole thing.
Perhaps I'm not an "average joe" in this matter, but I never look for documentation on the local disk. I *always* use Google first.
On Thu, 2005-02-24 at 13:32 -0800, Jamie Zawinski wrote:
Filiciano Matias wrote:
3- The average joe (me) expect to find the documentation in the same place than the program. A program with its documentation is the same whole thing.
Perhaps I'm not an "average joe" in this matter, but I never look for documentation on the local disk. I *always* use Google first.
+1
people use local docs?
-sv
Le jeudi 24 février 2005 à 17:44 -0500, seth vidal a écrit :
On Thu, 2005-02-24 at 13:32 -0800, Jamie Zawinski wrote:
Filiciano Matias wrote:
3- The average joe (me) expect to find the documentation in the same place than the program. A program with its documentation is the same whole thing.
Perhaps I'm not an "average joe" in this matter, but I never look for documentation on the local disk. I *always* use Google first.
+1
people use local docs?
Yes ! Many documentations are not online (think yum for example).
Filiciano Matias wrote:
Many documentations are not online (think yum for example).
Results 1 - 10 of about 167,000 for yum documentation
Le jeudi 24 février 2005 à 15:00 -0800, Jamie Zawinski a écrit :
Filiciano Matias wrote:
Many documentations are not online (think yum for example).
Results 1 - 10 of about 167,000 for yum documentation
I prefer this : $ rpm -q -l yum | egrep "(man)|(doc)" /usr/share/doc/yum-2.1.13 /usr/share/doc/yum-2.1.13/AUTHORS /usr/share/doc/yum-2.1.13/COPYING /usr/share/doc/yum-2.1.13/ChangeLog /usr/share/doc/yum-2.1.13/INSTALL /usr/share/doc/yum-2.1.13/README /usr/share/doc/yum-2.1.13/TODO /usr/share/man/man5/yum.conf.5.gz /usr/share/man/man8/yum-arch.8.gz /usr/share/man/man8/yum.8.gz
It's quicker and more accurate.
-- Jamie Zawinski jwz@jwz.org http://www.jwz.org/ jwz@dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/
Filiciano Matias wrote:
I prefer this : $ rpm -q -l yum | egrep "(man)|(doc)" /usr/share/doc/yum-2.1.13 /usr/share/doc/yum-2.1.13/AUTHORS /usr/share/doc/yum-2.1.13/COPYING /usr/share/doc/yum-2.1.13/ChangeLog /usr/share/doc/yum-2.1.13/INSTALL /usr/share/doc/yum-2.1.13/TODO
I'd classify those files as "useless bloat." I could not possibly be interested in those files if I didn't have the source code installed.
/usr/share/doc/yum-2.1.13/README /usr/share/man/man5/yum.conf.5.gz /usr/share/man/man8/yum-arch.8.gz /usr/share/man/man8/yum.8.gz
*That* is documentation.
It's quicker and more accurate.
See, in general, I find that not to be the case.
I find popularly-linked documents on the web to *always* be clearer, more informative, and less full of lies than local man pages.
On Thu, 2005-02-24 at 15:20 -0800, Jamie Zawinski wrote:
Filiciano Matias wrote:
I prefer this : $ rpm -q -l yum | egrep "(man)|(doc)" /usr/share/doc/yum-2.1.13 /usr/share/doc/yum-2.1.13/AUTHORS /usr/share/doc/yum-2.1.13/COPYING /usr/share/doc/yum-2.1.13/ChangeLog /usr/share/doc/yum-2.1.13/INSTALL /usr/share/doc/yum-2.1.13/TODO
I'd classify those files as "useless bloat." I could not possibly be interested in those files if I didn't have the source code installed.
I could. It describes the software package, I can see what new features are planned, how it changed in the last year (is it under active development?)
On Thu, 24 Feb 2005 15:20:37 -0800, Jamie Zawinski wrote:
Filiciano Matias wrote:
I prefer this : $ rpm -q -l yum | egrep "(man)|(doc)" /usr/share/doc/yum-2.1.13 /usr/share/doc/yum-2.1.13/AUTHORS /usr/share/doc/yum-2.1.13/COPYING /usr/share/doc/yum-2.1.13/ChangeLog /usr/share/doc/yum-2.1.13/INSTALL /usr/share/doc/yum-2.1.13/TODO
I'd classify those files as "useless bloat." I could not possibly be interested in those files if I didn't have the source code installed.
Then this was a bad example for you. :-) Yum files are python source code. I copied the files and created a version that used wget for downloading, which works much better than the python code over a dialup connection.
-Paul
On Thu, 2005-02-24 at 17:44 -0500, seth vidal wrote:
On Thu, 2005-02-24 at 13:32 -0800, Jamie Zawinski wrote:
Filiciano Matias wrote:
3- The average joe (me) expect to find the documentation in the same place than the program. A program with its documentation is the same whole thing.
Perhaps I'm not an "average joe" in this matter, but I never look for documentation on the local disk. I *always* use Google first.
+1
people use local docs?
Yes, frequently. Mostly on my laptop when I cannot get an Internet connection. But I am happy to explicitly install the docs I need for a separate source to keep the CD count down.
Keith.
On Thu, 2005-02-24 at 17:44 -0500, seth vidal wrote:
On Thu, 2005-02-24 at 13:32 -0800, Jamie Zawinski wrote:
Filiciano Matias wrote:
3- The average joe (me) expect to find the documentation in the same place than the program. A program with its documentation is the same whole thing.
Perhaps I'm not an "average joe" in this matter, but I never look for documentation on the local disk. I *always* use Google first.
+1
people use local docs?
Yes. There is *very little* worse, when looking for documentation, than finding documentation that doesn't match your version and only realizing that tiny little fact after you've spent a whole day trying to understand why something is not working as they should.
I *always* install and browse locally docs for stuff I use. People who look on the net first probably also wrote a browser :)
Not to mention devhelp is a godsend for anyone who is doing programming.
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If you ain’t there ain’t nobody else to impress <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
On Thu, 2005-02-24 at 17:44 -0500, seth vidal wrote:
3- The average joe (me) expect to find the documentation in the
same
place than the program. A program with its documentation is the
same
whole thing.
Perhaps I'm not an "average joe" in this matter, but I never look
for
documentation on the local disk. I *always* use Google first.
+1
people use local docs?
Think countries where the Internet is not so readily available. Or homes where there are no Internet connections. And don't even think 3rd world countries...
<anecdote> Someone came up to me at LinuxWorld after the talk I gave, and said they'd like to upgrade from RH9 to FC3. I said, grab the DVD. He said he lacked a DVDROM drive. I said, use yum :) He said he lacked an Internet connection. </anecdote>
He definitely needs local docs. And so do many others. And then there's devhelp as thomasvs mentions, which is mighty useful for programmers.
We should set a precedent that whatever goes in, must at least have a good man page, with good docs. In fact, this is what FreeBSD/OpenBSD has set as precedent, iirc - package doesn't go in, till it has docs
devel@lists.stg.fedoraproject.org
-
Aaron Bennett -
Alan Cox -
Alexandre Oliva -
Bill Nottingham -
Carwyn Edwards