the pro's for three distros:
gentoo: portage is bigger than yum and just as easy to use live cd
sabayon: binary builds of portage (for a fee, IIRC) anaconda
fedora: live cd anaconda
The drawback to fedora is, to my mind, rpm and yum. portage is superior. it's also capable, as sabayon has demonstrated, of distributing binaries.
Please switch to something like portage, which builds from source. This would eliminate, or at least, significantly reduce, the need for me to do things like build lshw from source because, and correct me if I'm wrong, it'd be easier to leave "in" and would require less maintenance.
Assuming all other things to be equal, as in only GPL 2 stuff is maintained, isn't portage easier to maintain? Wouldn't that mean more stuff for me (I mean users)?
Thank you,
Thufir
On Wed, 2007-06-27 at 06:14 +0000, Thufir wrote:
the pro's for three distros:
gentoo: portage is bigger than yum and just as easy to use live cd
sabayon: binary builds of portage (for a fee, IIRC) anaconda
fedora: live cd anaconda
The drawback to fedora is, to my mind, rpm and yum. portage is superior.
In what way is portage (which is essentially the "ports" methods from *BSD et. al) superior to yum / RPM? (Or, how is the latter inferior in your view, aside from "it doesn't have all the packages I want/need")
it's also capable, as sabayon has demonstrated, of distributing binaries.
Please switch to something like portage, which builds from source.
RPM has to get it's sources from somewhere. :-)
Ports / portage pulls the sources from the upstream site at build time, if I recall rightly. What happens if/when - and this has happened in the past IIRC - the upstream site tarballs are compromised? What's it's dependency handling like?
This would eliminate, or at least, significantly reduce, the need for me to do things like build lshw from source because, and correct me if I'm wrong, it'd be easier to leave "in" and would require less maintenance.
With portage, you'd still need to either build from ports or pull in the binary packages so I'm not seeing a distinct advantage in your proposal.
Assuming all other things to be equal, as in only GPL 2 stuff is maintained, isn't portage easier to maintain? Wouldn't that mean more stuff for me (I mean users)?
Someone still has to maintain the port, and that would consume the same amount of time and effort as maintaining an RPM as far as I can see it. No win there..
I think what you really want is an RPM for lshw - remembering that this is a community effort, you're quite welcome to have a go yourself (and there are plenty of people on this list who are more than capable in assisting in such an endeavour) or perhaps find an experienced packager that's also interested in maintaining such a package.
Changing package managers strikes me as an exercise in wheel reinvention :-)
Thank you,
Thufir
Michael.
On Wed, 27 Jun 2007 20:30:22 +1000, Michael Fleming wrote:
I think what you really want is an RPM for lshw - remembering that this is a community effort, you're quite welcome to have a go yourself (and there are plenty of people on this list who are more than capable in assisting in such an endeavour) or perhaps find an experienced packager that's also interested in maintaining such a package.
Review Request: lshw - Hardware Lister (lshw) https://bugzilla.redhat.com/229591
On Wed, Jun 27, 2007 at 08:30:22PM +1000, Michael Fleming wrote:
Someone still has to maintain the port, and that would consume the same amount of time and effort as maintaining an RPM as far as I can see it. No win there..
In fact, it seems to me that the real main difference between sabayon (gentoo) and fedora is not the port system. One could imagine a port system for for fedora/rpm too, maybe this allready exists, something like:
* get all the specfiles from a directory with specfiles * find out the build and runtime dependencies by parsing the spec files and construct a tree of needed build * use spectool -g on the spec file, or get it from a lookaside cache * rpmbuild -ba
In my opinion the real difference regarding packaging is that the gentoo ebuilds are much simpler than the specfiles because:
* there is no package split in gentoo * gento follows upstream even more closely than fedora, there is no real integration
The result is that it is certainly much easier to write ebuilds, that certainly explains for a part why there are more packages. The number of packagers and the time they dedicate to building packages would be the other parameter. These are numbers that is not easily found.
Regarding the number of packages, it seems to me that gentoo and debian or ubuntu have more packages than Fedora. But Fedora was really opened only recently to the community, and the number of packages is growing steadily, so it is possible that one day Fedora collection grows to the gentoo or debian/ubuntu level.
One advantage of Fedora over gentoo or debian is that there are paid redhat people for the maintainance of the most difficult and moving packages, like firefox, gcc, kernel, glibc, and so on....
-- Pat
On Wed, Jun 27, 2007 at 05:05:54PM +0200, Patrice Dumas wrote:
- find out the build and runtime dependencies by parsing the spec files and construct a tree of needed build
Run-time dependencies are mostly calculated and can't be extracted from the spec files.
- gento follows upstream even more closely than fedora, there is no real integration
Is this an advantage? ;-) A distro that does not integrate packages to make it consistent? That's how I read this, maybe you meant to say something different...
The result is that it is certainly much easier to write ebuilds, that certainly explains for a part why there are more packages. The number of packagers and the time they dedicate to building packages would be the other parameter. These are numbers that is not easily found.
Quality is more important then quantity.
One advantage of Fedora over gentoo or debian is that there are paid redhat people for the maintainance of the most difficult and moving packages, like firefox, gcc, kernel, glibc, and so on....
At least you discovered one advantage so far ;-).
On Wed, Jun 27, 2007 at 05:18:01PM +0200, Jos Vos wrote:
On Wed, Jun 27, 2007 at 05:05:54PM +0200, Patrice Dumas wrote:
- find out the build and runtime dependencies by parsing the spec files and construct a tree of needed build
Run-time dependencies are mostly calculated and can't be extracted from the spec files.
Indeed, I was wrong. As soon as a source package needs a build time dependency that has run time dependency this doesn't work anymore. Of course there would still be a minimal build root in any case since there are build time dependencies between bash, make, gcc, coreutils that are unworkable, even with run-time rpm dependencies.
I am wondering whether it would work if runtime requirements of just built packages are also considered.
- gento follows upstream even more closely than fedora, there is no real integration
Is this an advantage? ;-) A distro that does not integrate packages to make it consistent? That's how I read this, maybe you meant to say something different...
I am not saying that it is good or bad, I am stating a fact.
One advantage of Fedora over gentoo or debian is that there are paid redhat people for the maintainance of the most difficult and moving packages, like firefox, gcc, kernel, glibc, and so on....
At least you discovered one advantage so far ;-).
In all my mail I didn't tried to weight fedora against gentoo, I tried to disambiguate what the real differences are.
If you really want to know, I personnally prefer fedora, that's why I participate in fedora, and there are many reasons for that that are not about package availability, ease to write a package nor package integration. Still for some uses gentoo is nice, not for mine and maybe the gentoo community is nice, but I like the Fedora (with redhat) community.
-- Pat
On Wed, 27 Jun 2007 17:05:54 +0200, Patrice Dumas wrote:
In my opinion the real difference regarding packaging is that the gentoo ebuilds are much simpler than the specfiles because:
- there is no package split in gentoo * gento follows upstream even more
closely than fedora, there is no real integration
The result is that it is certainly much easier to write ebuilds, that certainly explains for a part why there are more packages. The number of packagers and the time they dedicate to building packages would be the other parameter. These are numbers that is not easily found.
Thanks for all the responses, they're quite informative :)
Bottom line is that I'd like to see a system which has more packages for the reasons described above. In my experience with portage, I could remove packages easily (although I don't know what actually happened behind the scenes).
I'd like to see Fedora consider some form of portage because that would, hopefully, increase the number of packages. All other things being equal, ebuilds are, apparently, easier to write.
-Thufir
On Wed, Jun 27, 2007 at 09:10:57PM +0000, Thufir wrote:
I'd like to see Fedora consider some form of portage because that would,
There is already something along that, recompiling the srpm with rpmbuild --rebuild, for example.
hopefully, increase the number of packages. All other things being equal, ebuilds are, apparently, easier to write.
No, they aren't. It could be argued that spec file and ebuilds are easier to write than the corresponding debian files, but in my opinion spec files are not harder nor easier to write than ebuilds.
What happens is that gentoo ebuilds are written with less care to integration than fedora specfiles, that whats make them easier to write in my opinion.
-- Pat
On Wed, Jun 27, 2007 at 11:14:47PM +0200, Patrice Dumas wrote:
What happens is that gentoo ebuilds are written with less care to integration than fedora specfiles, that whats make them easier to write in my opinion.
Oh puh-leeze. "Fedora has less packages than Gentoo because the gentoo developers do a crappy job" is kindergarden-level justification. I use both gentoo and fedora on a regular basis and they're both integrated, only differently. How many packages are available is a function of:
- infrastructure capability (a source distribution does not need a compile cluster)
- developers responsiveness (reviewing, QA, ...)
- apparent ease of adding new packages for new potential contributors
If you want more packages in Fedora (which is not a given), act on these points and especially the last two.
OG.
On Thu, Jun 28, 2007 at 12:01:38AM +0200, Olivier Galibert wrote:
On Wed, Jun 27, 2007 at 11:14:47PM +0200, Patrice Dumas wrote:
What happens is that gentoo ebuilds are written with less care to integration than fedora specfiles, that whats make them easier to write in my opinion.
Oh puh-leeze. "Fedora has less packages than Gentoo because the gentoo developers do a crappy job" is kindergarden-level
Less integration doesn't mean "crappy job", nor is it necessarily inferior. It is just another choice.
justification. I use both gentoo and fedora on a regular basis and they're both integrated, only differently.
Of course it depends on what you mean by 'integration'. In gentoo ebuilds there are less change/additions to upstream than in fedora.
How many packages are available is a function of:
infrastructure capability (a source distribution does not need a compile cluster)
developers responsiveness (reviewing, QA, ...)
apparent ease of adding new packages for new potential contributors
If you want more packages in Fedora (which is not a given), act on these points and especially the last two.
There are certainly also many other determinants to the number of packages available. But without looking at the reasons why there is a given number of packages, it is roughly: time to do a package * number of packager * time devoted per packager (the three terms are correlated, and the first one depends on the package so that's not a simple mean).
-- Pat
Patrice Dumas wrote:
There are certainly also many other determinants to the number of packages available. But without looking at the reasons why there is a given number of packages, it is roughly: time to do a package * number of packager * time devoted per packager (the three terms are correlated, and the first one depends on the package so that's not a simple mean).
I agree. However, I feel that a source-based system such as Portage is much less developer-friendly. For example, when I create a VM and use it to test my packages for an earlier release before I submit them to the build system, I know for certain that I am running the _exact_ same binaries as my users will be: same code paths, same compilation options, same library dependencies, same drivers, et al. This means that when I test it, I know for certain that my package will function on end-users' computers exactly as it does in my testing. When something goes wrong and someone posts a bug report, I can more precisely reproduce the backtrace or any other appropriate issue.
On the other hand, Gentoo's USE flags, compilation settings, optional dependencies, and linker flag combinations (among other build choices) mean that a Gentoo maintainer cannot ever fully test his package, as he cannot be sure what options the end-user will have enabled or not. (I remember a thread discussing something similar on the gentoo-dev mailing list not long ago. I don't remember who said it, but one of the developers posted that, with all combinations of _only_ USE flags , the amount of package combinations possible was something like 1000 times larger than the estimated age of the universe in seconds. Quite drastic, sure; but I wouldn't be surprised if that really were the case...)
Of course, there are those among users who rebuild their system or various component packages of it differently than what is shipped "by default" in Fedora; but they are likely much more sparse than those of Gentoo, and capable of tweaking other packages as needed to suit their systems. :)
On Wed, 27 Jun 2007 23:14:47 +0200, Patrice Dumas wrote:
What happens is that gentoo ebuilds are written with less care to integration than fedora specfiles, that whats make them easier to write in my opinion.
aha. thanks for explaining :)
Not to flog a dead horse, but isn't loose integration preferable to tight integration? Unless you're trying to squeeze a millisecond out of something, I don't see the advantage. Of course, I don't build rpm's either.
-thufir
On Wednesday 27 June 2007 18:03:02 Thufir wrote:
Unless you're trying to squeeze a millisecond out of something, I don't see the advantage. Of course, I don't build rpm's either.
"Integration" isn't about speed. It's about ensuring that the software works together, that it has been built with the right options to enable the desired features, that the features /work/ as expected, etc...
It's the kind of work we do to work towards a single dictionary system instead of one for each app (still working on this...)
It's the kind of work we do to try and make each desktop application use the same file selection tools, themes, etc...
On Wed, 27 Jun 2007 21:09:45 -0400, Jesse Keating wrote:
"Integration" isn't about speed. It's about ensuring that the software works together, that it has been built with the right options to enable the desired features, that the features /work/ as expected, etc...
It's the kind of work we do to work towards a single dictionary system instead of one for each app (still working on this...)
It's the kind of work we do to try and make each desktop application use the same file selection tools, themes, etc...
thanks for clarifying. This is getting close to naysaying, but I'd prefer more packages, easier to upgrade from fedora N to N+1, than integration. My personal preference.
Going back to expediency, ebuild ease of creation versus rpm ease of creation: e-builds are easier due to the looser integration? What are other factors, please?
thanks,
Thufir
Thufir <hawat.thufir <at> gmail.com> writes:
thanks for clarifying. This is getting close to naysaying, but I'd prefer more packages, easier to upgrade from fedora N to N+1, than integration. My personal preference.
Then I'd say you picked the wrong distribution. There are distributions out there for people with your preferences, you cited one already (Gentoo), why do you want Fedora to change to suit you?
I believe the integration work done in Fedora is essential, it's no use having thousands of packages if 10% of them don't run at all (because they used to work when they got submitted, but changes in libraries broke them, or worse, because they weren't tested at all due to "quantity over quality" mentality), 20% have bugs due to e.g. expecting files to be located in different places than they actually are in the distribution, half of them only work if you pick some specific USE flags or library versions which break the other half etc. Now, the actual numbers of problem packages in Gentoo might be much lower than that, but all those problems do exist in Gentoo or any other loosely-integrated distribution. The less integration work a distribution does, the worse the mess you end up with gets.
Kevin Kofler
On Wednesday, June 27, 2007 9:51 pm Thufir wrote:
Going back to expediency, ebuild ease of creation versus rpm ease of creation: e-builds are easier due to the looser integration? What are other factors, please?
I don't know about ebuilds, but RPM's are insanely easy to build if you know how. I mean, you can tear off a huge collection of RPM's in a very short time with a bit of knowledge of the spec file, and technically generating your own RPM's = compiling from source anyway (I did 5 packages yesterday in half an hour, though I doubt they'd fit the project's guidelines...).
I much prefer RPM to other systems I've used to handle this sort of thing, because they're easy to make and easy to use.
Kelly wrote:
On Wednesday, June 27, 2007 9:51 pm Thufir wrote:
Going back to expediency, ebuild ease of creation versus rpm ease of creation: e-builds are easier due to the looser integration? What are other factors, please?
I don't know about ebuilds, but RPM's are insanely easy to build if you know how. I mean, you can tear off a huge collection of RPM's in a very short time with a bit of knowledge of the spec file, and technically generating your own RPM's = compiling from source anyway (I did 5 packages yesterday in half an hour, though I doubt they'd fit the project's guidelines...).
I much prefer RPM to other systems I've used to handle this sort of thing, because they're easy to make and easy to use.
There is !no! difference in complexity of ebuild creation or rpm-spec creation. If you have a broken source tar-file and want to create an ebuild or a rpm-spec you have the !same! problems with your rpm-spec-file as with your ebuild file. You have nearly the same pre/post(un)install scripts to write and the runtime/buildtime dependency hell is also the same (ebuild:RDEPEND/DEPEND, spec:Requires/BuildRequires...) Therefore I can't see that ebuilds are looser integrated. Perhaps you must be a better shell programmer when you want to create your own ebuilds - that's all.
best regards
On Thu, Jun 28, 2007 at 01:01:25PM +0200, Jochen Schlick wrote:
spec:Requires/BuildRequires...) Therefore I can't see that ebuilds are looser integrated.
It isn't the ebuilds per se that are less integrated, but the gentoo packaging. If you want an example you can have a look at the wdm packaging (this is something I know because I maintain it in fedora). In gentoo it is simply installed, in Fedora I try to use a fedora background, an Xsession script that is the same than for gdm/kdm/..., and pre post-scripts that are the same than xdm, and lastly allow to use /usr/share/xsessions/ for the window manager lists.
-- Pat
On Thu, 28 Jun 2007 14:32:47 +0200, Patrice Dumas wrote:
spec:Requires/BuildRequires...) Therefore I can't see that ebuilds are looser integrated.
It isn't the ebuilds per se that are less integrated, but the gentoo packaging.
Perhaps my last post in the topic! :)
to clarify:
gentoo: loose integration greater quantity of packages
fedora: tight integration lesser quantity of packages
However, if it's about the same quantity of labor to create an e-build as to create an RPM, I'm not sure *why* the quantity of ebuilds is greater...
So, isn't some form of, perhaps, tightly integrated build-from source type packaging, the best of both worlds? (binaries for GNOME, and so forth, at request a la sabayon.)
-Thufir
On Fri, Jun 29, 2007 at 08:43:26AM +0000, Thufir wrote:
to clarify:
gentoo: loose integration greater quantity of packages
fedora: tight integration lesser quantity of packages
However, if it's about the same quantity of labor to create an e-build as to create an RPM, I'm not sure *why* the quantity of ebuilds is greater...
It is more labor to create an integrated package than to have less integration. But also the community may have different size and time.
So, isn't some form of, perhaps, tightly integrated build-from source type packaging, the best of both worlds? (binaries for GNOME, and so forth, at request a la sabayon.)
I don't think that the fact that Fedora isn't built from source affect in any way the number of packages available. What affects it is the number of people working on fedora and the difficulties of packaging.
-- Pat
On Fri, 29 Jun 2007, Thufir wrote:
On Thu, 28 Jun 2007 14:32:47 +0200, Patrice Dumas wrote:
It isn't the ebuilds per se that are less integrated, but the gentoo packaging.
Perhaps my last post in the topic! :)
to clarify:
gentoo: loose integration greater quantity of packages
fedora: tight integration lesser quantity of packages
However, if it's about the same quantity of labor to create an e-build as to create an RPM, I'm not sure *why* the quantity of ebuilds is greater...
So, isn't some form of, perhaps, tightly integrated build-from source type packaging, the best of both worlds? (binaries for GNOME, and so forth, at request a la sabayon.)
Whether the packages are binary or built-from-source is irrelevant. We could, if we wanted (for some reason), make lots of not-well-integrated RPMs, achieving the "we have all the packages in teh world!!!11" goal. Alas, the packaging quality wouldn't be much to write home about, and we'd probably have to relax or kill the packaging guidelines. What takes the hard work in Fedora is the tight integration. It has nothing to do with the nature of RPMs or yum. So, for your example, by providing "tightly integrated build-from source type packaging," we'd gain *nothing*. It'd take just as much work to write a tightly-integrated ebuild as it would to write a tightly-integrated spec. (I think, anyway -- people with more advanced experience with ebuilds are welcome to correct me if I'm mistaken.)
Jima
Thufir wrote:
Not to flog a dead horse, but isn't loose integration preferable to tight integration?
I guess that may be down to personal preference, but I'd opt for tight integration.
Unless you're trying to squeeze a millisecond out of something, I don't see the advantage.
Isnt that often a reason touted by Gentoo users as to why they love portage because they can shave a few milliseconds by rolling their own?
On Thu, 28 Jun 2007 02:11:19 +0100, Ian Chapman wrote:
Unless you're trying to squeeze a millisecond out of something, I don't see the advantage.
Isnt that often a reason touted by Gentoo users as to why they love portage because they can shave a few milliseconds by rolling their own?
Gentoo evolved, to my understanding, partly because there was a gcc which compiled something faster. So, when gentoo was first on the scene, that gcc compiled ______ better than other distro's, which gave better performance. Now everyone uses the same gcc and that benefit isn't really there anymore.
-Thufir
Thufir wrote:
I'd like to see Fedora consider some form of portage because that would, hopefully, increase the number of packages. All other things being equal, ebuilds are, apparently, easier to write.
Well from what I've seen of this discussion, "all other things being equal" isn't the case, hence why writing ebuilds is easier.
Thufir <hawat.thufir <at> gmail.com> writes:
The drawback to fedora is, to my mind, rpm and yum. portage is superior. it's also capable, as sabayon has demonstrated, of distributing binaries.
Portage: * parasites upstream projects for tarball downloads by default. Aside from the security concerns which have been raised elsewhere in this thread, this also: - steals bandwidth from upstream projects, - makes the user dependent on the upstream project's server being up (for every single upstream project) and still carrying the file they want (which isn't always the case, many upstream projects delete old versions, they don't have infinite webspace nor do they want people to download old buggy versions). So this really doesn't scale. It also doesn't comply with the GPL when distributing binaries. SRPMs carry the full source code. * rebuilds everything on the user's machine, so users can get completely different binaries depending on what version of GCC and glibc they happen to have installed when they build it, or even depending on what libraries are autodetected by the configure scripts. Some see this as a feature, but it makes handling bug reports a nightmare. * has only limited support for uninstalling. The biggest problem is that there's no reverse-dependency tracking, you can unmerge a library and it will not know there are still programs depending on it which will be broken by the unmerge. This can be particularly bad on upgrades: when you upgrade a library to an incompatible version (new soname), it will just do it even when there are still packages depending on the old version, breaking those packages. And no, rebuilding everything (i.e. emerge remerge world) isn't really an efficient solution to this problem.
Other source-based packaging systems, e.g. *BSD ports, share the same weaknesses.
RPMs do allow you to build from source, that's what specfiles and SRPMs are for. Writing your own specfile is not fundamentally different from writing your own portage recipe. Or you can always build from source into /usr/local; unpackaged packages (i.e. packages without a specfile or portage recipe) are also handled essentially the same way in both worlds.
Kevin Kofler
Kevin Kofler wrote:
Portage:
- parasites upstream projects for tarball downloads by default. Aside from
the security concerns which have been raised elsewhere in this thread, this also:
- steals bandwidth from upstream projects,
- makes the user dependent on the upstream project's server being up (for
every single upstream project) and still carrying the file they want (which isn't always the case, many upstream projects delete old versions, they don't have infinite webspace nor do they want people to download old buggy versions). So this really doesn't scale. It also doesn't comply with the GPL when distributing binaries. SRPMs carry the full source code.
Erm; No. Gentoo's portage mirrors have a "distfiles" directory that contains copies of all source tarballs for current versions of Portage packages. When one installs the package (via "emerge app-foo/bar" as root or similar), it attempts to download the tarball from this distfiles mirror. Only if it fails on multiple mirrors (or as is configured otherwise in /etc/make.conf) does it attempt to grab the sources from the upstream download location.
- has only limited support for uninstalling. The biggest problem is that
there's no reverse-dependency tracking, you can unmerge a library and it will not know there are still programs depending on it which will be broken by the unmerge. This can be particularly bad on upgrades: when you upgrade a library to an incompatible version (new soname), it will just do it even when there are still packages depending on the old version, breaking those packages. And no, rebuilding everything (i.e. emerge remerge world) isn't really an efficient solution to this problem.
Not necessarily; Portage has a tool called "revdep-rebuild" which takes care of rebuilding any package which no longer has proper dynamic library linkage.
RPMs do allow you to build from source, that's what specfiles and SRPMs are for. Writing your own specfile is not fundamentally different from writing your own portage recipe.
I concur with this. The first few RPM packages that I created were based quite heavily on Gentoo's ebuilds (not "recipes" - those are rPath/Conary) for them. I still use them from time to time to help track weird/unexpected dependencies.
Peter Gordon <peter <at> thecodergeek.com> writes:
Erm; No. Gentoo's portage mirrors have a "distfiles" directory that contains copies of all source tarballs for current versions of Portage packages. When one installs the package (via "emerge app-foo/bar" as root or similar), it attempts to download the tarball from this distfiles mirror. Only if it fails on multiple mirrors (or as is configured otherwise in /etc/make.conf) does it attempt to grab the sources from the upstream download location.
At least Gentoo tries to mirror the sources (still, why not fetch them _only_ from the distfiles mirrors?), other source-based distributions won't even bother doing that.
Not necessarily; Portage has a tool called "revdep-rebuild" which takes care of rebuilding any package which no longer has proper dynamic library linkage.
Oh, I didn't know about that tool. But why do you have to do that by hand? It should be automatic. Yum or apt won't update a library without also updating the applications which depend on it to versions built against the correct library.
I concur with this. The first few RPM packages that I created were based quite heavily on Gentoo's ebuilds (not "recipes" - those are rPath/Conary)
I don't know why I couldn't remember the specific term, I knew it of course. :-) But ebuilds, specfiles etc. are all "recipes". ;-)
Kevin Kofler
Kevin Kofler wrote:
Oh, I didn't know about that tool. But why do you have to do that by hand? It should be automatic. Yum or apt won't update a library without also updating the applications which depend on it to versions built against the correct library.
IIRC, whereas Yum and other binary-based systems such as APT track literal libraries (e.g., "libfoo.so.42(ABI_TAG)"), Portage only tracks per-package dependencies; so when you update one package it still notes that you have the dependent package installed. (I'm not too familiar with Portage internals though; so I could very well be completely pulling this out of my butt. ^_^)
I don't know why I couldn't remember the specific term, I knew it of course. :-) But ebuilds, specfiles etc. are all "recipes". ;-)
Technicalities of word choice - nothing more. :)
Peter Gordon <peter <at> thecodergeek.com> writes:
IIRC, whereas Yum and other binary-based systems such as APT track literal libraries (e.g., "libfoo.so.42(ABI_TAG)"),
That's how RPM does it (and yum and apt-rpm then compute dependencies based on that information), yes.
DPKG doesn't support that, so Debian's solution is to just call the package providing libfoo.so.42 libfoo42, so when libfoo.so.43 comes out, the packages will require libfoo43 and apt will know that libfoo42 is insufficient.
Kevin Kofler
On Wed, 2007-06-27 at 19:50 +0000, Kevin Kofler wrote:
DPKG doesn't support that, so Debian's solution is to just call the package providing libfoo.so.42 libfoo42, so when libfoo.so.43 comes out, the packages will require libfoo43 and apt will know that libfoo42 is insufficient.
Great; thank you for the clarification. :)
On Wed, 27 Jun 2007, Kevin Kofler wrote:
Peter Gordon <peter <at> thecodergeek.com> writes:
IIRC, whereas Yum and other binary-based systems such as APT track literal libraries (e.g., "libfoo.so.42(ABI_TAG)"),
That's how RPM does it (and yum and apt-rpm then compute dependencies based on that information), yes.
DPKG doesn't support that, so Debian's solution is to just call the package providing libfoo.so.42 libfoo42, so when libfoo.so.43 comes out, the packages will require libfoo43 and apt will know that libfoo42 is insufficient.
DPKG does support virtual provides/requires (which the soname dependencies essentially are) just fine, and .deb build can be told to extract automatic soname dependencies. The difference there is that the soname dependencies are resolved to package names at *build* time, not runtime like normally in rpm world. This means dramatically less junk for depsolver to handle, but it also means much, much stricter packaging policies must be used. Like the library package naming you mention, and that packages can't be split without rebuilding depending packages etc.
- Panu -
Dnia 27-06-2007, śro o godzinie 19:21 +0000, Kevin Kofler napisał(a):
Yum or apt won't update a library without also updating the applications which depend on it to versions built against the correct library.
Apt won't, but yum will without even notifying the user, it does that at least since F7 betas, when I started to use it for yum-presto (we're waiting for deltarpm support in apt). Fedora is one step closer to Gentoo now.
Lam
On Wed, 2007-06-27 at 23:21 +0200, Leszek Matok wrote:
Dnia 27-06-2007, śro o godzinie 19:21 +0000, Kevin Kofler napisał(a):
Yum or apt won't update a library without also updating the applications which depend on it to versions built against the correct library.
Apt won't, but yum will without even notifying the user, it does that at least since F7 betas, when I started to use it for yum-presto (we're waiting for deltarpm support in apt). Fedora is one step closer to Gentoo now.
It doesn't notify you that it is 'updating for dependencies'? Can you give me a test case so I can look at it?
Thanks, -sv
Dnia 27-06-2007, śro o godzinie 17:30 -0400, seth vidal napisał(a):
It doesn't notify you that it is 'updating for dependencies'? Can you give me a test case so I can look at it?
I was talking about upgrading a library and breaking dependencies. Kevin's right, though, it's fixed in 3.2.1, I haven't upgraded my Rawhide for few days now, so I stand corrected.
An open question: is there a way to make yum update my rawhide, when there are broken dependencies in the repos? Apt gives me "upgrade" which upgrades only packages that can be upgraded, leaving out a small subset of packages with broken interdependencies. Apt also gives me "dist-upgrade", which removes packages that would otherwise keep others from upgrading, depending on older versions. Not to mention apt-shell, where I can decide on a per-package basis. Yum, OTOH, simply refuses to upgrade at all, spitting some depsolving errors. Going for "yum install <list of 100 packages>" isn't an option, you know :)
Lam
On Thu, 2007-06-28 at 07:55 +0200, Leszek Matok wrote:
Dnia 27-06-2007, śro o godzinie 17:30 -0400, seth vidal napisał(a):
It doesn't notify you that it is 'updating for dependencies'? Can you give me a test case so I can look at it?
I was talking about upgrading a library and breaking dependencies. Kevin's right, though, it's fixed in 3.2.1, I haven't upgraded my Rawhide for few days now, so I stand corrected.
An open question: is there a way to make yum update my rawhide, when there are broken dependencies in the repos? Apt gives me "upgrade" which upgrades only packages that can be upgraded, leaving out a small subset of packages with broken interdependencies. Apt also gives me "dist-upgrade", which removes packages that would otherwise keep others from upgrading, depending on older versions. Not to mention apt-shell, where I can decide on a per-package basis. Yum, OTOH, simply refuses to upgrade at all, spitting some depsolving errors. Going for "yum install <list of 100 packages>" isn't an option, you know :)
look at the skip-broken plugin, it is packaged in f7 and rawhide.
-sv
Leszek Matok <Lam <at> Lam.pl> writes:
Dnia 27-06-2007, śro o godzinie 19:21 +0000, Kevin Kofler napisał(a):
Yum or apt won't update a library without also updating the applications which depend on it to versions built against the correct library.
Apt won't, but yum will without even notifying the user, it does that at least since F7 betas, when I started to use it for yum-presto (we're waiting for deltarpm support in apt). Fedora is one step closer to Gentoo now.
That's a bug then. Probably the "yum doesn't resolve dependencies properly" bug in 3.2.0 which is already fixed in 3.2.1 (which should be out as an F7 update shortly).
Kevin Kofler
On Wed, Jun 27, 2007 at 07:21:25PM +0000, Kevin Kofler wrote:
Peter Gordon <peter <at> thecodergeek.com> writes:
Not necessarily; Portage has a tool called "revdep-rebuild" which takes care of rebuilding any package which no longer has proper dynamic library linkage.
Oh, I didn't know about that tool. But why do you have to do that by hand? It should be automatic. Yum or apt won't update a library without also updating the applications which depend on it to versions built against the correct library.
Because you often do not want to do it immediatly after the specific update that changed the library.
The main advantage of gentoo over fedora is the continuous upgrade path. You do not need to reinstall everything from scratch every 6 months just to keep up-to-date. The main disadvantage is the difficulty (read, near impossibility) of manipulating a source distribution on a lab scale.
OG.
Olivier Galibert <galibert <at> pobox.com> writes:
Because you often do not want to do it immediatly after the specific update that changed the library.
You want broken apps instead?!
The main advantage of gentoo over fedora is the continuous upgrade path. You do not need to reinstall everything from scratch every 6 months just to keep up-to-date.
You don't need to do that with Fedora either, that's what Anaconda's upgrade mode is for. You can even upgrade with yum or apt (not really supported though).
Kevin Kofler
On Wed, Jun 27, 2007 at 10:46:42PM +0000, Kevin Kofler wrote:
Olivier Galibert <galibert <at> pobox.com> writes:
Because you often do not want to do it immediatly after the specific update that changed the library.
You want broken apps instead?!
Please re-engage your brain. I usually update all the *other* applications and libraries that need to be compiled because of a new version and *then* I ask revdep-rebuild to recompile what is still broken. revdep-rebuild always recompiles the same version than what is currently installed, not the most up-to-date available one.
The main advantage of gentoo over fedora is the continuous upgrade path. You do not need to reinstall everything from scratch every 6 months just to keep up-to-date.
You don't need to do that with Fedora either, that's what Anaconda's upgrade mode is for. You can even upgrade with yum or apt (not really supported though).
Everything is in that "not really supported though". I'm not too enthusiastic about having to go in front of and reboot the 200+ computers we manage one by one with a usb key just to run anaconda upgrade.
Someday, maybe, anaconda will be able to do an install/upgrade from a running installation. Not sure it's anywhere in the plans though. Is the code to test if the pid is not too high still there? Meanwhile, I've already done complete gentoo installations in a chroot of a mounted external usb disk, which worked beautifully once installed in the recieving laptop. That were painless HD upgrades.
OG.
Olivier Galibert <galibert <at> pobox.com> writes:
Please re-engage your brain. I usually update all the *other* applications and libraries that need to be compiled because of a new version and *then* I ask revdep-rebuild to recompile what is still broken. revdep-rebuild always recompiles the same version than what is currently installed, not the most up-to-date available one.
Then you should do those updates in one transaction, and the automatic revdep-rebuild should happen at the end of the transaction, not in the middle. (Of course, it gets more complicated because apps which are needed for the remaining upgrades need to be working, so they might need a rebuild even during the transaction, but that can be figured out programmatically too.)
Everything is in that "not really supported though". I'm not too enthusiastic about having to go in front of and reboot the 200+ computers we manage one by one with a usb key just to run anaconda upgrade.
Edit your /etc/apt/sources.list and/or /etc/apt/sources.list.d/*.list to point to the newer Fedora, then run: apt-get update apt-get dist-upgrade and you're running the new Fedora version. That can even be scripted for your 200+ computers (just use sed, cat and/or rm for the sources.list editing, then apt-get update && apt-get -y dist-upgrade).
Kevin Kofler
On Wed, 27 Jun 2007 12:10:02 -0700, Peter Gordon wrote:
- has only limited support for uninstalling. The biggest problem is
that there's no reverse-dependency tracking, you can unmerge a library and it will not know there are still programs depending on it which will be broken by the unmerge. This can be particularly bad on upgrades: when you upgrade a library to an incompatible version (new soname), it will just do it even when there are still packages depending on the old version, breaking those packages. And no, rebuilding everything (i.e. emerge remerge world) isn't really an efficient solution to this problem.
Not necessarily; Portage has a tool called "revdep-rebuild" which takes care of rebuilding any package which no longer has proper dynamic library linkage.
If a portage type system can uninstall well, and I believe that to be the case, that seals it for me. The advantages of a portage type system are greater than those of a yum type system.
Sabayon may have screwed things up, but a system which compiles most things from source in a portage type way, with a few exceptions which are time intensive, would be easier to maintain and thus larger. Open Office, the kernel, things like that could be prebuilt.
I mean this really as food for thought for you guys. FC6 and Fedora 7 greatly improved in terms of the ease of use of yum. However, there's a FC6 yum repo and a Fedora 7 repo. Why? That seems like completely unnecessary duplication which wouldn't occur in a build-from-source package manager. As a user, I hesitate to upgrade because of the lag as third party repos slowly catch up to Fedora versions.
Again, thank you for the lively discussion :)
-Thufir
On Wed, Jun 27, 2007 at 09:21:11PM +0000, Thufir wrote:
If a portage type system can uninstall well, and I believe that to be the case, that seals it for me. The advantages of a portage type system are greater than those of a yum type system.
I think I can't disagree more.
Sabayon may have screwed things up, but a system which compiles most things from source in a portage type way, with a few exceptions which are time intensive, would be easier to maintain and thus larger. Open Office, the kernel, things like that could be prebuilt.
Easier to maintain, for whom? The package/distro builders? Certainly not for an average end-user.
Reading opinions like these, I have the impression that most people only think of individual, hacker-type users, not about, say, system administrators maintaining large networks of systems, having to support those systems (and users) easily, etc.
On Wed, Jun 27, 2007 at 11:59:30PM +0200, Jos Vos wrote:
Reading opinions like these, I have the impression that most people only think of individual, hacker-type users, not about, say, system administrators maintaining large networks of systems, having to support those systems (and users) easily, etc.
Well, Fedora is becoming more and more hostile to the sysadmin population as time goes too, so...
OG.
Olivier Galibert galibert@pobox.com wrote:
On Wed, Jun 27, 2007 at 11:59:30PM +0200, Jos Vos wrote:
Reading opinions like these, I have the impression that most people only think of individual, hacker-type users, not about, say, system administrators maintaining large networks of systems, having to support those systems (and users) easily, etc.
Well, Fedora is becoming more and more hostile to the sysadmin population as time goes too, so...
If so, that is a (meta)bug well worth fixing... Details, please?
On Thu, Jun 28, 2007 at 11:40:27AM -0400, Horst H. von Brand wrote:
Olivier Galibert galibert@pobox.com wrote:
On Wed, Jun 27, 2007 at 11:59:30PM +0200, Jos Vos wrote:
Reading opinions like these, I have the impression that most people only think of individual, hacker-type users, not about, say, system administrators maintaining large networks of systems, having to support those systems (and users) easily, etc.
Well, Fedora is becoming more and more hostile to the sysadmin population as time goes too, so...
If so, that is a (meta)bug well worth fixing... Details, please?
Well, from my point of view from a part-time sysadmin in a lab with 200+ computers to handle, the two main problems are: - 6-months release cycle, with reinstall needed - loss of Core
I'm going to expand on that a little. My users need an installation which is reasonably up-to-date (recent firefox and openoffice for a start) and which does not require them to change their habits too much. I need an installation I can put semi-automatically on a computer with a minimum of handholding and which includes 99% of what all my users will ever need (hard drives are cheaper than my time).
One solution is to have a local package repository with a good coverage, and a boot+kickstart that does an everything install of that repository, configures things locally, but still asks for things like partitioning, keyboard type, ip addresses or root password. And points yum at the repository for updates.
Then the question becomes "what do I put in the repository", "how do I update it", and "how often do I have to go back in front of the computer to do a full reinstall".
For the first two questions, "Core" was a godsend, and "Prime" is nowhere near it. Core was a set of packages you could install without conflicts in in reasonable space (12G for fc5 on amd64) and, once added a small number of packages from extras, pbone and local compiles it provided enough choice to my users to be happy (decent KDE, decent Gnome, other less-known wms) and do their work. Prime is a live-cd, hence much smaller no matter what happens, which is already talking about removing KDE, and from which is rather annoying to extract a usable repository base.
Also Core had specific updates which also did not conflict and merging them in was relatively easy.
Now I'm going to have to find a way to make a list of packages we want in the repository and ensure they don't conflict and cover what my users need. "Not happy" doesn't even begin to cover it.
Oh, before you start saying that I should give my users the choice of what to install, don't forget two things:
- most of them don't *want* to choose, they have other things to do with their lives, they'd just like to have what they need when they need it
- only 15-20% of the computers are desktop, rest is servers of one kind or another
And on top of that, you add the 6-months release cycle. Let's see what it gives, for, say Fedora 7:
- june 2007, f7 is out. Wait for it to stabilize, give it two months
- august 2007, try to build a working installation repository and local configuration, that's easily going to take a month since it's definitively not the only thing one has to do
- september 2007, install f7 on the desktop of 2-3 volunteers,give them some time to find out all that's missing
- october 2007, all the missing packages have been added, the kinks fixed, start installing f7 on some servers (secondary but used file server, things like that). See how it goes.
- november 2007, f8 is out, the installation is already becoming obsolete
- december 2007, several emails with lkml/autofs/whatever later the kinks are out on the server installs and scsi, nfs, autofs work correctly again. Start installing on more servers, using the winter vacations in order not to be too blocking
- january 2008, start installing on the desktops. Add the missing packages the users find out.
- february 2008, reinstall the clusters (yes, plural), fight with oscar until it behaves
- april 2008, f9 is out
- june 2008, f7 is EOLed, no more updates, including security
At fc3 or fc5 time, the delay before eol-ing was two years and not one, and the presence of core made the "I'm missing a package" kinks much rarer. It *was* annoying, but less.
OG.
On Thursday 28 June 2007 14:05:41 Olivier Galibert wrote:
Well, from my point of view from a part-time sysadmin in a lab with 200+ computers to handle, the two main problems are:
- 6-months release cycle, with reinstall needed
- loss of Core
I'm going to expand on that a little. My users need an installation which is reasonably up-to-date (recent firefox and openoffice for a start) and which does not require them to change their habits too much. I need an installation I can put semi-automatically on a computer with a minimum of handholding and which includes 99% of what all my users will ever need (hard drives are cheaper than my time).
One solution is to have a local package repository with a good coverage, and a boot+kickstart that does an everything install of that repository, configures things locally, but still asks for things like partitioning, keyboard type, ip addresses or root password. And points yum at the repository for updates.
Then the question becomes "what do I put in the repository", "how do I update it", and "how often do I have to go back in front of the computer to do a full reinstall".
For the first two questions, "Core" was a godsend, and "Prime" is nowhere near it. Core was a set of packages you could install without conflicts in in reasonable space (12G for fc5 on amd64) and, once added a small number of packages from extras, pbone and local compiles it provided enough choice to my users to be happy (decent KDE, decent Gnome, other less-known wms) and do their work. Prime is a live-cd, hence much smaller no matter what happens, which is already talking about removing KDE, and from which is rather annoying to extract a usable repository base.
Also Core had specific updates which also did not conflict and merging them in was relatively easy.
I think you need to look closer. Prime went away around Test2 perhaps. Now there is the "Fedora" spin, which isn't a LiveCD at all, it's in fact very close to what "Core" used to be.
As for updates, I'm really not sure why you don't mirror the updates in their entirety so that not only what you install, but what your users may install after the fact will be able to be updated. Yes we've had some broken deps in F7 updates thus far, but we're working to shore up those gaps in the tools.
Now I'm going to have to find a way to make a list of packages we want in the repository and ensure they don't conflict and cover what my users need. "Not happy" doesn't even begin to cover it.
As stated, look at the Fedora spin.
Oh, before you start saying that I should give my users the choice of what to install, don't forget two things:
- most of them don't *want* to choose, they have other things to do
with their lives, they'd just like to have what they need when they need it
- only 15-20% of the computers are desktop, rest is servers of one
kind or another
And on top of that, you add the 6-months release cycle. Let's see what it gives, for, say Fedora 7:
- june 2007, f7 is out. Wait for it to stabilize, give it two months
That's just silly and a waste of time.
- august 2007, try to build a working installation repository and
local configuration, that's easily going to take a month since it's definitively not the only thing one has to do
- september 2007, install f7 on the desktop of 2-3 volunteers,give
them some time to find out all that's missing
- october 2007, all the missing packages have been added, the kinks
fixed, start installing f7 on some servers (secondary but used file server, things like that). See how it goes.
Complete hyperbole. Start with Fedora spin, it's probably exactly what you want. Could have that done in early July.
- november 2007, f8 is out, the installation is already becoming
obsolete
- december 2007, several emails with lkml/autofs/whatever later the
kinks are out on the server installs and scsi, nfs, autofs work correctly again. Start installing on more servers, using the winter vacations in order not to be too blocking
- january 2008, start installing on the desktops. Add the missing
packages the users find out.
- february 2008, reinstall the clusters (yes, plural), fight with
oscar until it behaves
april 2008, f9 is out
june 2008, f7 is EOLed, no more updates, including security
At fc3 or fc5 time, the delay before eol-ing was two years and not one, and the presence of core made the "I'm missing a package" kinks much rarer. It *was* annoying, but less.
It was /not/ 2 years. FC3 went EOL when FC5 Test2 came out. There was Legacy, but that never really lived up to what I promised. Now we've made the "official" lifespan even longer than before. A month's time to prepare for a new release + 12~ months of updates is pretty reasonable. Anything longer and you really are looking at RHEL like timelines.
Olivier Galibert wrote:
On Thu, Jun 28, 2007 at 11:40:27AM -0400, Horst H. von Brand wrote:
Olivier Galibert galibert@pobox.com wrote:
On Wed, Jun 27, 2007 at 11:59:30PM +0200, Jos Vos wrote:
Reading opinions like these, I have the impression that most people only think of individual, hacker-type users, not about, say, system administrators maintaining large networks of systems, having to support those systems (and users) easily, etc.
Well, Fedora is becoming more and more hostile to the sysadmin population as time goes too, so...
If so, that is a (meta)bug well worth fixing... Details, please?
Well, from my point of view from a part-time sysadmin in a lab with 200+ computers to handle, the two main problems are:
- 6-months release cycle, with reinstall needed
6 month release cycles are not a new change and shouldn't be cited as "increasingly hostile". If you consider shorter release cycles as not appropriate for you, Fedora has always been that way.
Reinstall is not needed. You can do upgrades via Anaconda. Upgrades via the package managers might not be official supported but it is definitely doable and I have done for several releases successfully.
For the first two questions, "Core" was a godsend, and "Prime" is nowhere near it.
Actually the renamed "Prime" spin which is called "Fedora" spin is very close to what "Core" was. That is explicitly the purpose of that spin.
At fc3 or fc5 time, the delay before eol-ing was two years and not one,
Incorrect. Fedora updates cycle was about 9 months and extended to about 13 months before the release of Fedora 7.
Rahul
On Thu, 28 Jun 2007 20:05:41 +0200, Olivier Galibert wrote:
- 6-months release cycle, with reinstall needed
As the OP, I feel entitled to bitch "me too". However, I'm learning a lot about yum, almost all good :)
The re-install part is or is not related to yum and tight integration?
-Thufir
Thufir <hawat.thufir <at> gmail.com> writes:
The re-install part is or is not related to yum and tight integration?
It's simply wrong. No reinstalls are needed, the installer can do upgrades or you can even just upgrade with yum or apt-rpm (not recommended, but that doesn't mean "impossible").
The fact that you have to upgrade to a new distribution version at all as opposed to getting updated to the next version progressively is a decision which has nothing to do with yum/rpm nor with tight integration. It's perfectly possible to do rolling releases with rpm. For example, Rawhide works that way. It isn't recommended for everyday use though (just like Gentoo ~x86 or ~x86_64 installs).
Kevin Kofler
Sabayon may have screwed things up, but a system which compiles most things from source in a portage type way, with a few exceptions which are time intensive, would be easier to maintain and thus larger. Open Office, the kernel, things like that could be prebuilt.
Easier to maintain, for whom? The package/distro builders? Certainly not for an average end-user.
Reading opinions like these, I have the impression that most people only think of individual, hacker-type users, not about, say, system administrators maintaining large networks of systems, having to support those systems (and users) easily, etc.
I think that's the crux of it... not many of us running many servers enjoy the idea of our machines chugging away CPU cycles compiling all sorts of new packages.
Seems like the main issue here is wanting/needing more packages available for Fedora rather than whether yum vs portage is appropriate. So pitch in and help package or make some suggestions on streamlining the process... asking Fedora to switch to portage is just not a very realistic thing to ask for IMO. :)
Ray
On Wed, Jun 27, 2007 at 09:21:11PM +0000, Thufir wrote:
I mean this really as food for thought for you guys. FC6 and Fedora 7 greatly improved in terms of the ease of use of yum. However, there's a FC6 yum repo and a Fedora 7 repo. Why? That seems like completely unnecessary duplication which wouldn't occur in a build-from-source package manager. As a user, I hesitate to upgrade because of the lag as third party repos slowly catch up to Fedora versions.
Whether the spec file should be different on F6 or F7 is left to the packager. I guess portage also knows about releases.
It is also possible that Gentoo is slower to change things in the packaging practices, while in fedora things change rapidly, and this would be in line with gentoo packaging being minor. Once again the difference lie more in the distro scope and target than in the packaging system used. If you come with a rpm based distro with a gentoo like packaging (meaning no split, no integration) then all you say above will still be relevant. So rpm vs portage is not the issue here.
-- Pat
Thufir wrote:
Sabayon may have screwed things up, but a system which compiles most things from source in a portage type way, with a few exceptions which are time intensive, would be easier to maintain and thus larger.
Seriously, how can something where I have to compile most things from source be easier to maintain? You have an extra layer of complexity. In addition to satisfying dependancies at the install, you also have to satisfy dependancies for compiling. Personally I'd rather just install binaries and get on with things rather than waiting for things to compile. I know a guy who's a big Gentoo fan and he has a particular dislike of redhat/fedora. I asked him what he particularly liked about Gentoo and he said Portage and the fact that he can compile stuff from source and tweak the compile options to optimise it, so it runs faster. Fair enough, sounds kinda reasonable until he admitted he waited 11 days for X to compile on his 486. And for what, the chance of it starting up 2 seconds quicker? I know extreme example, but... :-) Each to their own, I suppose.
On Wednesday, June 27, 2007 2:14 am Thufir wrote:
The drawback to fedora is, to my mind, rpm and yum. portage is superior. it's also capable, as sabayon has demonstrated, of distributing binaries.
Portage, superior? Um, no.
I ran Sabayon once. Couldn't update the base system to the latest versions of the programs because the system had almost no dependency resolution at all, and I actually had to manually update each package, one at a time, to get it to update properly. If I just tried updating like in Fedora, the system would die after the first three or four packages, reporting a missing dependency the system seemed incapable of doing itself.
ons, 27 06 2007 kl. 06:14 +0000, skrev Thufir:
Please switch to something like portage, which builds from source. This would eliminate, or at least, significantly reduce, the need for me to do things like build lshw from source because, and correct me if I'm wrong, it'd be easier to leave "in" and would require less maintenance.
That is the single least QA friendly thing I've ever heard uttered. By not just allowing but encouraging users to mix and match compiler and linker settings you make it entirely impossible to do proper QA on the software as things stand. We need a fixed point of reference to do our job.
As someone with a lengthy past in the Gentoo world I will be happy to provide you a list of the kinds of bug reports that would cause but let's not embarrass anyone with the horror stories.
If such a model was ever adopted in Fedora I would be the first to leave as it would make my continued contribution to the project impossibly hard, it's tough enough to keep up with the small area I have to do testing on already as it is.
- David Nielsen
On Thu, 28 Jun 2007 08:08:22 +0200, David Nielsen wrote:
As someone with a lengthy past in the Gentoo world I will be happy to provide you a list of the kinds of bug reports that would cause but let's not embarrass anyone with the horror stories.
I admit to great ignorance as the actual coding involved, and was giving my impression.
However, leaving aside my particular solution, do you see the same problem (s) as me? constantly adding third party yum repository's, which are always behind, and repeatedly having to go outside of yum to install stuff? Surely there *must* be something better than yum. what?
I meant my post, yes, as a direct challenge to the status quoue, but in a good spirit; in which spirit it seems to have been taken.
-Thufir
fre, 29 06 2007 kl. 08:34 +0000, skrev Thufir:
On Thu, 28 Jun 2007 08:08:22 +0200, David Nielsen wrote:
As someone with a lengthy past in the Gentoo world I will be happy to provide you a list of the kinds of bug reports that would cause but let's not embarrass anyone with the horror stories.
I admit to great ignorance as the actual coding involved, and was giving my impression.
However, leaving aside my particular solution, do you see the same problem (s) as me? constantly adding third party yum repository's, which are always behind, and repeatedly having to go outside of yum to install stuff? Surely there *must* be something better than yum. what?
I meant my post, yes, as a direct challenge to the status quoue, but in a good spirit; in which spirit it seems to have been taken.
As for 3rd part repos I use the Fedora one and Livna. If an application you need is missing then you can add it to the wishlist on the wiki and we'll get around to packaging it (bearing legality of course). I use the Development branch and even in that setting I rarely experience problems with dependencies.
- David