----- "John5342" john5342@googlemail.com wrote:
2009/7/7 Ding-Yi Chen dchen@redhat.com:
於 二,2009-07-07 於 14:44 +0100,John5342 提到:
2009/7/7 Ding-Yi Chen dchen@redhat.com:
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.
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. :-)
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.
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?
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.
And packagers shouldnt have to.
What? Why? Does it logical to expect a stable system if critical dependency information is missing?
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.
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?
BTW, mind sharing your program? :-)
2009/7/8 Ding Yi Chen dchen@redhat.com:
----- "John5342" john5342@googlemail.com wrote:
2009/7/7 Ding-Yi Chen dchen@redhat.com:
於 二,2009-07-07 於 14:44 +0100,John5342 提到:
2009/7/7 Ding-Yi Chen dchen@redhat.com:
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!
Ding Yi Chen wrote:
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.
Selective updates are not really tested in practice and tend not to work. You're expected to get ALL stable updates, not just one. The old RHL advisories made this clear: | Before applying this update, make sure all previously released errata | relevant to your system have been applied.
Kevin Kofler