2009/7/8 Ding Yi Chen <dchen@xxxxxxxxxx>: > > ----- "John5342" <john5342@xxxxxxxxxxxxxx> wrote: > >> 2009/7/7 Ding-Yi Chen <dchen@xxxxxxxxxx>: >> > >> > 於 二，2009-07-07 於 14:44 +0100，John5342 提到： >> >> 2009/7/7 Ding-Yi Chen <dchen@xxxxxxxxxx>: >> >> > >> >> > Any comments? >> >> >> >> In theory your proposal sounds great but i see just one major flaw >> >> that probably doesn't have a solution. Your idea of packages being >> >> built based on dependencies should work great apart from the fact >> that >> >> most packages don't tend to have hard dependencies on versions. >> >> Hypothetically in F11 package X-1.2.X relies on package Y-1.2. >> Later >> >> in the release cycle Y-1.3 is released followed later by X-1.3. >> Eve >> >> though X-1.3 actually requires Y-1.3 the maintainer probably never >> >> thinks to update the required version (assuming there even was one >> in >> >> the first place). Now your system can easily fail. It picks X-1.3 >> from >> >> F-11 (because thats the latest one) but Y-1.3 isn't allowed >> (because >> >> one of its dependencies is black listed) so it falls back to Y-1.2 >> >> which was the latest in F-10. Everything builds fine because they >> are >> >> source compatible but Y-1.2 doesnt have a crucial bug fixed. Now >> your >> >> software is broken. >> > >> > All systems have bugs and may break. So you don't use any of them? >> :-) >> >> Of course all systems have bugs. However some are minor whilst others >> are so much work to make them usable that they are simply not worth >> it. Stuff that requires constant user intervention to cope with >> scenarios that cannot be automated is one such major issue. >> >> > The scenario you raised could happen if not so many people use the >> > package X. Otherwise, it would likely be spot by people who use >> > yum update X, as Y-1.3 is not dragged in. >> > Given X-1.3 is broken without Y-1.3, thus bug will likely be spot. >> >> Wouldn't be spotted until it is used in your system. It wouldn't be >> used during standard usage because in a normal release both would be >> updated at the same time (or at least in the right order) so the >> scenario never happens. > > Firstly, not all people turn the automatic upgrade on. > Secondly, there are folks use rpm -hiv or build from srpm. > In that case, they are more likely to spot the bugs. I am not talking about upgrades. I am talking about updates. Most people just run updates when packagekit (or similar) tells them to. In a proper release updates are released together. In Denture they will be updated out of order and from various different releases. As for people rebuilding from srpms etc they represent a minority and it is in any case irrelevant. >> > Well, Y depends on black-listed packages doesn't mean Y cannot be >> > upgraded at all. As long as the the newer Y does not require higher >> > version of black-listed packages. >> >> Of course Y can be updated but not necessarily to the required >> version. If the world was perfect all versions of packages would >> contain the exact versions required for things to work and your >> proposed system would either update fine or refuse to with a message >> if a dependency is blacklisted or unavailable as a recent enough >> version. >> >> However unfortunately for the same reasons i stated already virtually >> no package will state the dependant versions accurately enough to do >> what you want. > > If what you said is completely true, I would not even bother to propose Denture. :-) What i said is plain and simple fact. The scenario i mentioned is one of several points of failure. I am not suggesting it is a problem with Denture itself but it is a problem with the real world. Thats just life. >> > But if black-listed packages requires Y, or Y is black-listed, >> > then Y will not be upgraded. >> > In those cases, it is expected behavior that X should not be >> upgraded to >> > X-1.3 because Y cannot be upgraded to Y-1.3. >> >> That is of course assuming X-1.3 has an explicit dependency on Y-1.3. >> It would be lovely if all packages has these versioned dependencies >> and a lot have automatically due to things like sonames but take the >> scenario where the soname is the same but the presence of the bug is >> not. > > If X-1.3 does not specify Y-1.3 as dependency, I don't think > yum update X will pull Y-1.3, even with the current version. > Not to mention people who use rpm directly or build from srpm. > So please file bug to X, don't blame Denture. This isn't about whether Y-1.3 will be pulled in. If you do what the vast majority of users do then you will get the equivelant of yum update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3 will still be updated siply because there is a later version. When you update using Denture however you could easily end up with X-1.3 and Y-1.2 for any number of reasons. >> > Yes, you find out the limitation of Denture, but no, >> > Denture is not broken. :-) >> >> Denture is not broken. Unfortunately though Denture only works in the >> ideal world. In reality though scenarios like i just mentioned happen >> all the time (along with many other similar issues) and the scenario >> i >> mentioned would break the users system and Denture has no way of >> knowing until it is too late. > > So do other package managers. > Tell me, why are you so sure that the current version packages > don't break the system secretly and user and the package managers > has no way of knowing until it is too late? If you read all i wrote then you will find that has been answered thoroughly already >> >> >> Believe it or not i actually tried something similar for some of >> my >> >> internal servers and i like the idea but its impossible to get the >> >> dependencies right which makes the whole idea a no go. >> > >> > Believe it or not I actually tried something similar, >> > but by hand though. >> > >> > I agree some maintainers does not accurately specify the >> dependency. >> > but it is not beyond fix. >> >> It is not some. It is more like most. How many packages do you see >> with the following for every single requires and build requires: >> BuildRequires: X-devel = X.X.X-X >> Requires: X = X.X.X-X > > After a quick peek of the packages I maintain or am interested in: > > 7 packages provide the version info of each dependency. > 5 packages provide the version info for some critical package (see dvdauthor.spec for example). > 5 packages does not specified it at all. 3 of which are man-pages :-) > > Only 15% of the packages (exclude the man-pages) does not provide any version information. > It may show the laziness of upstream or maintainer, but most of the case, > it's meant to work with older version. You have found the exceptions there. Try looking at some others. >> And packagers shouldnt have to. > > What? Why? Does it logical to expect a stable system if > critical dependency information is missing? I am sure even your dependency versions become stale. Taking your example of dvdauthor BuildRequires: libpng-devel BuildRequires: flex BuildRequires: bison BuildRequires: fribidi-devel BuildRequires: freetype-devel BuildRequires: GraphicsMagick-devel BuildRequires: autoconf automake gettext-devel In a single release you perhaps can be pretty sure that the versions in the build root are good enough to satisfy dvdauthor. If on the other hand you end up with a version of one of these packages from a previous release due to blacklisting then things may well start to break. Would you however insist that all of these are bugs? >> apart from anything else it would >> mean >> that every single time somebody rebuilds a package all packages that >> depend on it would need rebuilding even if the update is binary >> compatible yet at the same time the only way to stop the scenario i >> mentioned from happening is to do exactly that. > > Yes, but let the computer to the rebuilding while you enjoy the result. :-) > Is a rebuilding bad thing? According to my FreeBSD experience, not at all. The result could be great but i can be pretty sure that the actually stability of a partially updated system is probably much worse than rawhide and people who are happy with that level of stability would ore than likely just prefer actual recent release >> During a normal release bugs are easily spotted and fixed and >> scenarios like i mentioned will mostly never even happen anyway but >> mixing packages from different releases will potentially create an >> infinite number of combinations and almost certainly break. > > If this is true, then Denture can happily live with it. > Almost certainly break? You mentioned that > you did have similar system, if it almost certainly break, > how come you still like the idea? I like the idea because the concept is great. The idea that you can run whatever version of whatever package you want and get the best of all worlds is a nice dream but unfortunately i also know that it is only a dream and in real life it simply can't work because the huge requirements that Denture would place on packaging just can't be done. If nothing else because of manpower. Most maintainers wont have time to test every possible combination of versions accross multiple releases just so that Denture stands a chance of working. When i was working on my project i quickly realised that for the reasons i have been trying to explain (falling on deaf ears apparently) and many others besides it simply wasn't feasible. It could be done but the effort of maintaining the fedora packages to a level that would allow Denture to work would probably require double the package maintainers we already have. Good luck with that one. > BTW, mind sharing your program? :-) I probably have it somewhere on backup but i never bother restoring backups of projects that are doomed to failure. If i ever come across the backup i will send it you but i don't see much point in searching through Exabytes of data just for that. I really wish you all the best. I really do. I would love to be surprised and see it work but i won't be holding my breath. Good luck! -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
