Weekly Edition
Return to the Distributions page
| |||||||||||||
Fedora 7 release delayed
One of the big Features of Fedora 7 is a merged core and extras. In order to accomplish this, we need some improvements to the buildsystem currently used by Fedora Extras. We need these improvements done or mostly done by the Feature Freeze of Fedora 7, which was originally set to be the 20th of February, 4 days from now. It is very clear that these changes will not be ready by then. To accomplish these changes (and others) in time for the Feature Freeze, we have added another month to the schedule, introducing a Test 4, and moving the Feature Freeze as well as String Freeze up to Test 3 freeze, March 19. This moves the general availability date from April 26 to May 24. For further discussion on this topic, please use the fedora-maintainers list, which I am attempting to set reply-to. For reference: http://fedoraproject.org/wiki/Releases/7/Schedule -- Jesse Keating Release Engineer: Fedora -- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list (Log in to post comments)
Fedora 7 release delayed Posted Feb 19, 2007 2:50 UTC (Mon) by kornak (guest, #17589) [Link] Perhaps the cost of merging core and extras outway the benefits. It isinevitable that an "extras" like repository will eventually emerge anyway. Maybe a standard guideline for independent repositories would be more beneficial. Centrallizing a vast repository is always troublesome. I propose the reverse, more distribution of repositories. I envision repositories growing quickly in a peer to peer fashion with a web of trust. Maybe a repository torrent so that a yum client could be a server as well. One might build a list of trusted servlets that you would use. A rating system if you will that one could share with other trusted clients. Maybe I'm dreaming. Thoughts?
Thoughts Posted Feb 19, 2007 5:44 UTC (Mon) by Ed_L. (guest, #24287) [Link] I think you are proposing the very sort of licensing anarchy the Fedora folks are assiduously trying to avoid. There are already plenty of repo sites that cater to those who wish to put anything of any origin on their Fedora systems. And that's OK (at least to a point...). But such repos don't call themselves "Fedora" anything, and it appears Fedora wishes to keep it that way.
Thoughts Posted Feb 19, 2007 8:14 UTC (Mon) by kornak (guest, #17589) [Link] Forgive me, but I was not proposing anthing of the sort. Where did you getlicensing scheme from my comments? I simply proposed a more distributed scheme which is by its very nature under the communities control rather than a central entity. How does this propose a proprietaty licensing scheme? The masses decide because they may build or distribute the packages. One might subscribe to a central authority as well as a few peers you trust. This has the side benefit of providing a popularity rating for each package.
Thoughts Posted Feb 19, 2007 22:35 UTC (Mon) by Ed_L. (guest, #24287) [Link] Rightly or perhaps wrongly, I got the idea that Fedora would likely lose control of its repository license scheme from"Centrallizing a vast repository is always troublesome. I propose the reverse, more distribution of repositories. I envision repositories growing quickly in a peer to peer fashion with a web of trust." From your reply, I gather license impurity was not your intent at all. (I rather doubted it was in the first place.) I am pointing out that it is a likely consequence. You seem to think such can be avoided through suitable guidelines and safeguards. I remain skeptical, though I do agree that one big pile of garbage is harder to maintain than several smaller ones. Just harder under which to hide incriminating evidence :) I used to have a list of three or four indie repos that I used with a now-defunct FC5 install. Livna was one, there were several others. Most were good at what they did, made no pretense, and played well with others. How does such differ from what you propose? My point is that Fedora wishes to ensure, to the extent possible, that anything associated with the "Fedora" mark meets Fedora's licensing requirements. And if there is a distributed P2P repo way of doing that then fine, we're in agreement. Thanks!
Thoughts Posted Feb 20, 2007 2:10 UTC (Tue) by kornak (guest, #17589) [Link] Perhaps my ideas where mis-interpreted, but, I simply proposed a lesscentralized methodology for Fedora. If it is a "Fedora" signed package, then it will hold true to the "Fedora" ideals. I think this merging will in the end be counter-productive as it will increase the burden on Fedora to maintain the lot. Perhaps the P2P argument doesn't fit in to this particular argument, but it does extend the idea of a more distributed repository model. The primary differnce in my idea of using P2P is that packages can be maintained centrally or be distributed and still be Fedora packages, or they could be "liva", or "atrpms", or "dries, etc. The more we have in the game the better. With P2P, anybody can join the game, even if they have a single package or script they wish to share. Whether they choose GPL or BSD or whatever is entirely up to them. This does not taint Fedora as only Fedora can sign their own packages.
they should just bite the bullet. Posted Feb 19, 2007 6:14 UTC (Mon) by drag (subscriber, #31333) [Link] If they were smart they'd base their packaging sceme around Debian's.
Not use deb's or anything like that, but have a way to translate deb-src packages into spec files for RPMs and have a strong basis for starting annew.
I like debian and all that, but the real reason this would be a good idea is because the problems they are facing are probably already mostly solved by Debian.
That and Debian has a hell of a lot more _supported_ packages in main then anything Fedora + third party repos ever had. They could adopt those, repackage them for RPM and then instead of dicking solving problems that have been solved they can go and streamline functionality and improve support for things that Debian doesn't support well yet.
Plus it would be nice to have a bit more consistancy across linux distros.
One nice example of what Debian does is make sure that all commands have man pages and they include documentation and text files pulled the source tarball into /usr/share/doc/$packagename which is _very_ usefull.
I don't mean that they should _base_ their system on Debian or worry about 100% compatability or use deb files themselves or anything. Just use their packages for the basis for creating Fedora-specific packages.
Once these distros start getting in a more consistant packages then maybe in a couple years some Freedesktop.org people (or whoever) can get together and make a specification for standardizing package policies.
they should just bite the bullet. Posted Feb 19, 2007 13:02 UTC (Mon) by khim (subscriber, #9252) [Link] I don't mean that they should _base_ their system on Debian or worry about 100% compatibility or use deb files themselves or anything. Just use their packages for the basis for creating Fedora-specific packages. If you don't use the Debian philosophy of system organization - then what's the point ? It's actually easier to convert Fedora to .deb then to convert it to Debian-style layout. But if you don't use Debian's layout, if you don't use Debian's tools - then what's the point ? They fact remains: RedHat/Fedora is as old as Debian, it was developed in parallel and while it borrows ideas from Debian (and Debian borrows ideas from RedHat!) it's way too late to reinvent the whole system. May it'll be better to abandon the Fedora/RedHat development and switch to gNewSense, but to abandon the Fedora and create something new Debian-based instead... what's the point again ?
they should just bite the bullet. Posted Feb 19, 2007 16:30 UTC (Mon) by seyman (subscriber, #1172) [Link] That and Debian has a hell of a lot more _supported_ packages in main then anything Fedora + third party repos ever had. There are currently 10241 packages in Debian testing. There are 8187 in Fedora 6 (2242 in Core, 5945, in Extras). If you add third party repos to that, I suspect that "a hell of a lot more" should be replaced by "a little bit less".
they should just bite the bullet. Posted Feb 19, 2007 17:02 UTC (Mon) by amacater (subscriber, #790) [Link] Approximately 17769 in Debian testing (18178 if you include the contrib andnon-free repositories as well). You were saying?
they should just bite the bullet. Posted Feb 19, 2007 17:38 UTC (Mon) by seyman (subscriber, #1172) [Link] Approximately 17769 in Debian testing (18178 if you include the contrib and non-free repositories as well). You were saying? I'm saying you're counting binary packages and I'm counting source packages.
they should just bite the bullet. Posted Feb 19, 2007 17:48 UTC (Mon) by drag (subscriber, #31333) [Link] I have 19571 packages aviable for my Debian Sid PowerPC (including debian-multimedia.org and a couple small third party repos for specific programs)
And that's powerpc.
All those are also found, of course, on x86, x86-64, and What is in Debian Main is aviable in ARM, Sparc and several other architectures.
Arm is as popular as anything nowadays, for instance. Used in things like OpenMoko and those Nokia tablets, so is Powerpc (which is possibly more popular) Wouldn't it be nice if you could have a Fedora embedded edition for those things?
Then you should also probably check out http://apt-get.org/ which has untold amounts of packages from third parties. Then you have all the odd BS people are creating for Ubuntu and Linspire's commercial desktop software integration efforts.
I am not dissing Fedora, they are a lot better then they used to be package wise. And I do not have ANY delusions over any mythical superiority of debs over rpm or anything silly like that.
But, seriously, do you want:
I know it probably will never happen, though.
they should just bite the bullet. Posted Feb 19, 2007 20:31 UTC (Mon) by eklitzke (subscriber, #36426) [Link] There are a number of reasons why this would be extremely difficult, if not impossible. For one, the deb and rpm formats are not 100% compatible -- if translating between them was easy, the tools for doing this (e.g. alien) would suck less.
Other reasons not to move from rpm include things like SELinux. If you look at the spec files in Fedora CVS, a number of them have special build provisions for building SELinux packages. IIRC, you can put commands in a spec file that are only applied if you are running SELinux, for example. Nowadays _every_ package (at least in core) is expected to work in an SELinux environment, and RHEL/Fedora are really the only viable SELinux platforms exactly because they have an order of magnitude more experience and time invested in this issue. To move to deb would involve rewriting parts of the deb infrastructure.
Also, I hate to be partisan about this, but rpm really is a superior package format to deb. If you've done any kind of packaging, this is evident pretty much from the get go. The biggest problems with rpm have to do with rpmlib and not the rpm package format. Moving to deb would definitely be a step backwards, from a purely technical perspective.
Debian does have a lot more packages than Fedora. But a _lot_ of these are abandoned packages that haven't been updated in years and may not work, but just haven't been removed from the package tree (I believe this is Debian policy). If you don't include such packages in the count, and also omit non-free packages, my best guess is that Debian would only provide something like 10% more packages.
P.S. Fedora also includes man pages and documentation. The big difference with Debian is that they have a policy not to distribute anything without documentation, so a lot of the time Debian developers end up writing the man pages/documentation (although you will notice that there are still quite a few packages that are undocumented). For example, GNU does not provide a tar man page! The only one for GNU tar is the one written by Debian developers. Sometimes the Fedora devs don't pull in the Debian documentation, but it's hard to hold them too much at fault for that.
they should just bite the bullet. Posted Feb 19, 2007 21:16 UTC (Mon) by drag (subscriber, #31333) [Link] I don't think that Debian has a lot of abandoned packages. They ahve some, but most of that software is obsolete. You can see orphaned packages here:http://www.debian.org/devel/wnpp/orphaned
And I've never ran into packages that don't work. Occasionally you get broken packages that would cause some sort of deadlock when figuring out dependancies, but that's something that happens in development branch and is temporary.
Plus as time goes by they've gotten better and better.
I understand that RPM is generally superior to Debs, but that is pretty much irrelevent to the end user's point of view. Seriously.
What makes or breaks a good package is quality control, consistancy between packages, documentation, and good itegration into the existing system. That's about it. It doesn't matter if it's portage or debs or rpm. The package format is incidental, almost to the point of irrelevency.
If it was the other way around I'd be saying the same things about Debian and Fedora.
The only thing that I am concerned about is that all of this software packaging nonsense is a duplication of effort on a massive scale.
The amount of manhours going into repackaging software, quality assurance testing, and everything involved is just enourmous.
It's not just making a distribution anymore. Debian and Fedora are creating a snapshot of all of the Free software aviable to anyone. Incompatable catalogs of not just the kernel and userland, but _EVERYTHING_.
Everything anywere that anybody could possibly want about anything. Every peice of software, every bit of code. Codified, rationalished, cross referenced, dependancies worked out. Everything.
It's not just 'distributions' anymore, it's 2 incompatable snapshots of the entire FOSS world. It's like having to build two egyption pyramids because the Pharaoh's wife can't figure out if she likes stones with rounded edges or stones with pointy edges.
Either way I just don't see it working out in the long run. Is Fedora people going to be perpetually scambling to compile and test packages for the rest of their lives while the Debian folks fail to get a distro out of the door on time from here and unto the end of time?
they should just bite the bullet. Posted Feb 19, 2007 22:01 UTC (Mon) by bojan (subscriber, #14302) [Link] > Is Fedora people going to be perpetually scambling to compile and test packages for the rest of their lives while the Debian folks fail to get a distro out of the door on time from here and unto the end of time?
Packages in Fedora change constantly and a random contributor may find that what used to build on Fedora X won't in the current development tree, because the organisation of packages and integration between them has been improved (well, changed at any rate :-). This is how the progress in made in Fedora - in small, incremental steps - Fedora releases.
But, and more importantly, this fast changing environment actually enables Red Hat folk and other Fedora contributors to experiment with the direction of the distribution rapidly.
> The only thing that I am concerned about is that all of this software packaging nonsense is a duplication of effort on a massive scale.
Yeah, it may look like that (I dreamed of a Grand Unified Linux Distro before :-), but it is also a good thing as it addresses different needs of different people. It also makes sure that upstream development is kept honest, as many different groups of people are attempting to bend the same software to do slightly different things.
Don't worry too much about people actually doing this. They either get paid to do it or want to do it. There is really no harm ;-)
they should just bite the bullet. Posted Feb 20, 2007 0:44 UTC (Tue) by drag (subscriber, #31333) [Link] Well I would actually considure Debian changes in small incremental steps.
If you track Debian Testing or Debian Sid then it's just constant upgrade of the system. Very rarely anything big breaks. It's been much much more kind to me tracking Debian Testing then trying to keep up with Fedora releases. I've done this successfully for years and never needed to reinstall.
In comaprision it's actually been difficult for me to keep up with Fedora releases. When I did keep up the majority of software that I used that wasn't part of Fedora Core wasn't aviable. Basicly ended up being that I couldn't upgrade to a new release of Fedora for the first 3 months or so.
Then again maybe things improved. The last time I tried Fedora was with FC4 and when I upgraded to that there was _no_ support for anything extra that I needed, even after I waited for a while. Maybe, hopefully, Fedora has finally figured out how to play well with others (ie third party repositories) and this including extras seems a step in the right direction.
But that's neither here nor there.
I suppose if they want to put all the extra work into just re-packaging software that's already been effectively packaged by other people then who am I to say they are wrong.
they should just bite the bullet. Posted Feb 20, 2007 1:23 UTC (Tue) by bojan (subscriber, #14302) [Link] > put all the extra work into just re-packaging software
Fedora releases are much more than that. As eklitzke pointed out in this discussion, SELinux integration is such an example. There are numerous other examples where a new release of Fedora featured major changes that would require you to upgrade every single package on the system anyway. And sometimes, doing so would render you system unusable if done by upgrading packages on the running system (e.g. switch to udev).
> In comaprision it's actually been difficult for me to keep up with Fedora releases.
I always have several machines with Fedora on them and it is true that each new release brings new "challenges" when upgrading (yes, I _always_ upgrade, never wipe clean, unless it's a new machine). But, that's what Fedora is all about - fast change. Obviously, not everyone's cup of tea, which is OK.
> Maybe, hopefully, Fedora has finally figured out how to play well with others (ie third party repositories) and this including extras seems a step in the right direction.
I think that Fedora isn't overly concerned with third party repositories (e.g. Livna, Fresh RPMS etc.). It is these repositories that need to adjust to the next release of Fedora, not the other way around. Usually, they do a pretty good job of doing that, since they also have a development repository, which is kept up to date with Rawhide (i.e. current Fedora developement tree).
Fedora change policy is similar to that of Linux kernel - changes happen all the time and are waiting for no one. You either fix your code to fit into the new way of doing things, or it won't work.
they should just bite the bullet. Posted Feb 20, 2007 6:19 UTC (Tue) by drag (subscriber, #31333) [Link] ""Fedora releases are much more than that. As eklitzke pointed out in this discussion, SELinux integration is such an example. There are numerous other examples where a new release of Fedora featured major changes that would require you to upgrade every single package on the system anyway.""
I am not advocating binary compatability at all. At this time that is just a waste of time and effort.
I am not saying that Fedora should use debian's repositories.
I am saying that they should just leech as much as possible off of debian. Following the policies and practices and standards.
Finding a intellegent way to translate debian's deb-src packages and build system to RPM spec files. Which then can be used to build packages.
So match the orginization of the packages, match how the library versioning works. Match how they divide up the original tarballs into invidual packages and so on and so forth.
Binary and package for package compatability is a lost cause, IMO.
So you take how they are setup, translate that to spec files, use that to build the rpms, test it and add whatever you need to it and then your finished onto the next problem.
Then when you improve packages and do features then you make the patches public and Debian will take that and incorporate it back into their system. This is how it works, more or less, with the Debian-Ubuntu (and other debian based systems) relationship.
Then after a few releases of doing that then it may (or may not) make sense to do higher amounts of syncronization in terms of library versioning scemes and make cross-distribution dependencing tracking easier for developers and end users.
""I think that Fedora isn't overly concerned with third party repositories (e.g. Livna, Fresh RPMS etc.). It is these repositories that need to adjust to the next release of Fedora, not the other way around. Usually, they do a pretty good job of doing that, since they also have a development repository, which is kept up to date with Rawhide (i.e. current Fedora developement tree).
Fedora change policy is similar to that of Linux kernel - changes happen all the time and are waiting for no one. You either fix your code to fit into the new way of doing things, or it won't work.""
I guess so. I suppose then Fedora realy is just for developers and not for normal people.
they should just bite the bullet. Posted Feb 20, 2007 8:23 UTC (Tue) by drag (subscriber, #31333) [Link] btw I know this will probably never happen and I am not realy all that worried about it.
Leeching among distributions? Posted Feb 27, 2007 13:49 UTC (Tue) by vonbrand (subscriber, #4458) [Link] I am not saying that Fedora should use debian's repositories. Don't worry, they are leeching. Look at the changelogs for the Fedora packages, they often credit patches to Debian, and I'm sure it is the other way around too. Besides, Fedora's policy is to push for upstream changes where feasible, so everybody benefits. Getting the packages from one system to build on the other is hard, getting them seamlessly integrated is much harder still. Yes, it is manual work. Stuff like Linux Standard Base help in creating some order among distributions, sure. OTOH, Debian's performance WRT releases is dismal, to say the least... Fedora has managed to crank out 6 releases in a pretty short timeframe, mostly not too far from schedule. Debian should learn from Fedora here... so it is not that Debian's process is vastly superior either.
they should just bite the bullet. Posted Feb 20, 2007 0:22 UTC (Tue) by ofeeley (subscriber, #36105) [Link] "(although you will notice that there are still quite a few packages that are undocumented). For example, GNU does not provide a tar man page!"
No man page != no documentation. There's a perfectly good info page available. (And there's no point digressing into a disparagement of info -- it's documentation.)
Info pages Posted Feb 20, 2007 2:01 UTC (Tue) by Ed_L. (guest, #24287) [Link] Tar man pages vs. info is actually a pretty good example in favour of info. The tar documentation is extensive enough that a single man page would be about as wieldly as the single man page for bash.
Fortunately, bash and tar both have good info documentation.
Info pages Posted Feb 20, 2007 14:09 UTC (Tue) by ofeeley (subscriber, #36105) [Link] Oh, I agree completely. I love info. I find it much easier to use than man pages.
info schminfo Posted Feb 22, 2007 7:13 UTC (Thu) by ldo (subscriber, #40946) [Link] info is crap. Whatever won't fit into a man page, put into HTML. It's so much easier to read, navigate, search, publish on the Web etc.
info schminfo Posted Feb 22, 2007 15:26 UTC (Thu) by nix (subscriber, #2304) [Link] Your mileage definitely varies here. (e.g. how easy is it to regexp search a subtree of web pages? Essentially impossible without a lot of extra infrastructure, that's how easy.)
info schminfo Posted Mar 1, 2007 3:53 UTC (Thu) by roelofs (subscriber, #2599) [Link] Your mileage definitely varies here. (e.g. how easy is it to regexp search a subtree of web pages? Essentially impossible without a lot of extra infrastructure, that's how easy.)But that's just extra UI fluff. (I'm not saying it's not useful UI fluff...) Is there any particularly good reason at this point why the underlying file format couldn't be HTML (or XHTML)? The info client could still behave as you like, including multi-page regex grep. Meanwhile, those of us who favor portability could use a standard web browser as the client. Greg
|
|||||||||||||