Hi,
I checked on the percentage of how many packages do use disttags these days. And since I was at it I did some historical reseach to see the tendency (I don't have access to Pre-Extras, so the Extras and Sum slots for FC1 and FC2 are empty). The results are quite interesting:
release Fedora Core Fedora Extras Sum 1 2 / 936 <1% 2 0 / 947 0% 3 9 / 970 1% 711 / 1115 64% 720 / 2085 35% 4 12 / 965 1% 1530 / 1786 86% 1542 / 2751 56% 5 36 / 1157 3% 2686 / 2778 97% 2722 / 3935 69% 6 336 / 1154 29% 3008 / 3068 98% 3344 / 4222 79% rawhide 846 / 1218 69% 2833 / 2897 98% 3679 / 4115 89%
Some notes:
o Fedora Extras has always used more packages w/ disttags than w/o, the tendency up to its last incarnation in FC6 was steadily increasing until it reached 98% and remained at that level.
o Fedora Core has adopted disttags very late in comparison to Fedora Extras, but also has the steepest growth - since FC6 every third package has already been disttag'ed, by F7 it's more than two thirds. This is mostly due to the fact that previously the Fedora Core buildsystem would not support setting the disttag macros, while the Fedora Extras buildsystem did so for the very beginning.
o In their sum the disttagged packages have also reached the majority since FC4.
Conclusions:
o The disttag idiom was very successful, even though it is not mandatory it managed to be adopted in over 98% of Fedora Extras and 69% of Fedora Core.
o From EPEL's POV, since it is a Fedora Extras rebuild for RHEL the package pool comes from the 98% of disttagged packages. Although RHEL is smaller than Fedora Core and one would assume some packages in EPEL coming from Fedora Core and thus getting at a lower than 98% share, current EPEL shows that almost all packages but some special ones like epel-release use the disttag.
o For any other application that would require mandatory disttags like for example disttags of fc7.89, fc7.90 etc for rawhide and test releases this setup is not very far away. Looking at the sum of packages, this could happen by F8 by itself (the sum gains at least 10% each year and there are only 11% left).
Suggestions:
o watch the tendency and when it really reaches about 100% (e.g. F8) think about what gains mandatory disttags could bring us. If it is worth it fix the remaining few packages to use disttags (note: not all packages make sense to carry one, firmwares or XXX-release packages for example don't really need them)
o continue suggesting the use of disttags to new packagers - even though optional it should be the recommended way to package things up.
On Fri, Apr 06, 2007 at 06:04:56PM +0200, Axel Thimm wrote:
Hi,
o continue suggesting the use of disttags to new packagers - even though optional it should be the recommended way to package things up.
But remember that for data noarch packages, and software noarch packages that don't in stall in versionned interpreter directory disttages are harmfull.
I though there was something in the wiki about that but I can't find it.
-- Pat
Patrice Dumas schrieb:
On Fri, Apr 06, 2007 at 06:04:56PM +0200, Axel Thimm wrote:
o continue suggesting the use of disttags to new packagers - even though optional it should be the recommended way to package things up.
But remember that for data noarch packages, and software noarch packages that don't in stall in versionned interpreter directory disttages are harmfull.
harmfull maybe is a bit strong word, but you have a point.
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
CU thl
On Fri, Apr 06, 2007 at 07:12:53PM +0200, Thorsten Leemhuis wrote:
Patrice Dumas schrieb:
On Fri, Apr 06, 2007 at 06:04:56PM +0200, Axel Thimm wrote:
o continue suggesting the use of disttags to new packagers - even though optional it should be the recommended way to package things up.
But remember that for data noarch packages, and software noarch packages that don't in stall in versionned interpreter directory disttages are harmfull.
harmfull maybe is a bit strong word, but you have a point.
Indeed I shouldn't have used harmfull. But being forced to download and install, say, 30M for no reason should be avoided.
-- Pat
Thorsten Leemhuis wrote:
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
I would recommend at least one rebuild of a package just before release though for everything but pure data packages. I've been surprised by what has changed and caused failures.
On Friday 06 April 2007 13:52:12 Orion Poplawski wrote:
I would recommend at least one rebuild of a package just before release though for everything but pure data packages. I've been surprised by what has changed and caused failures.
Continuous rebuilds are done, just not imported. I think this is great, we get the benefit without the churn. Churning the entire package set without reason is ridiculous and may do more harm than good. See Matt D's core/extras rebuild reports.
On Fri, Apr 06, 2007 at 02:06:52PM -0400, Jesse Keating wrote:
On Friday 06 April 2007 13:52:12 Orion Poplawski wrote:
I would recommend at least one rebuild of a package just before release though for everything but pure data packages. I've been surprised by what has changed and caused failures.
Continuous rebuilds are done, just not imported. I think this is great, we get the benefit without the churn. Churning the entire package set without reason is ridiculous and may do more harm than good. See Matt D's core/extras rebuild reports.
But nobody tests them. Only fatal build errors are probed that way.
Axel Thimm wrote :
On Fri, Apr 06, 2007 at 02:06:52PM -0400, Jesse Keating wrote:
On Friday 06 April 2007 13:52:12 Orion Poplawski wrote:
I would recommend at least one rebuild of a package just before release though for everything but pure data packages. I've been surprised by what has changed and caused failures.
Continuous rebuilds are done, just not imported. I think this is great, we get the benefit without the churn. Churning the entire package set without reason is ridiculous and may do more harm than good. See Matt D's core/extras rebuild reports.
But nobody tests them. Only fatal build errors are probed that way.
IIRC this is not true : A rebuild is also considered "failed" if it creates packages with different requires or provides than the ones from the packages in the repository.
Matthias
On Mon, Apr 16, 2007 at 11:54:15AM +0200, Matthias Saou wrote:
Axel Thimm wrote :
On Fri, Apr 06, 2007 at 02:06:52PM -0400, Jesse Keating wrote:
On Friday 06 April 2007 13:52:12 Orion Poplawski wrote:
I would recommend at least one rebuild of a package just before release though for everything but pure data packages. I've been surprised by what has changed and caused failures.
Continuous rebuilds are done, just not imported. I think this is great, we get the benefit without the churn. Churning the entire package set without reason is ridiculous and may do more harm than good. See Matt D's core/extras rebuild reports.
But nobody tests them. Only fatal build errors are probed that way.
IIRC this is not true : A rebuild is also considered "failed" if it creates packages with different requires or provides than the ones from the packages in the repository.
So, if the build generates the same sonames, it is already considered run-time tested?
On 16.04.2007 11:54, Matthias Saou wrote:
IIRC this is not true : A rebuild is also considered "failed" if it creates packages with different requires or provides than the ones from the packages in the repository.
That would be news to me. I'm not aware of any such checks in the Extras buildsys, and none of my packages ever stumbled over such checks -- which I'd say would be likely.
CU thl
Thorsten Leemhuis wrote :
On 16.04.2007 11:54, Matthias Saou wrote:
IIRC this is not true : A rebuild is also considered "failed" if it creates packages with different requires or provides than the ones from the packages in the repository.
That would be news to me. I'm not aware of any such checks in the Extras buildsys, and none of my packages ever stumbled over such checks -- which I'd say would be likely.
I'm not referring to the buildsys, but to Matt Domsch's automated rebuilds and reports.
Matthias
On 16.04.2007 13:04, Matthias Saou wrote:
Thorsten Leemhuis wrote :
On 16.04.2007 11:54, Matthias Saou wrote:
IIRC this is not true : A rebuild is also considered "failed" if it creates packages with different requires or provides than the ones from the packages in the repository.
That would be news to me. I'm not aware of any such checks in the Extras buildsys, and none of my packages ever stumbled over such checks -- which I'd say would be likely.
I'm not referring to the buildsys, but to Matt Domsch's automated rebuilds and reports.
Ohh, sorry, that wasn't obvious to me in that context.
/me should have looked closer
CU thl
Jesse Keating wrote:
Continuous rebuilds are done, just not imported. I think this is
great, we
get the benefit without the churn. Churning the entire package set without reason is ridiculous and may do more harm than good. See Matt D's core/extras rebuild reports.
Had forgotten about that. With those checks in place I guess we are okay.
So, are we going to worry about .fc6 packages in FC7?
On Friday 06 April 2007 14:23:42 Orion Poplawski wrote:
So, are we going to worry about .fc6 packages in FC7?
No, I don't believe we are. Maybe a FAQ about the fact that our releases inherit from previous releases and some things don't get/need rebuilt. We are efficient in that we only rebuild for technical reasons.
Orion Poplawski schrieb:
Thorsten Leemhuis wrote:
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
I would recommend at least one rebuild of a package just before release though for everything but pure data packages. I've been surprised by what has changed and caused failures.
Just before release sounds bad, as that could create new bugs. So before test2 normally (test3 for FC7 as we have a test4) would be be better IMHO. But even better would be to build the package to a your home machine or into a scratch repo where it gets deleted after building (Iand not pushed) -- that way people that live in areas where internet bandwidth is costly are not forced to download a new package on update when nothing changed.
CU thl
On 4/6/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
huh? How is this even physically possible?
/me am confused.
Christopher Stone schrieb:
On 4/6/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
huh? How is this even physically possible? /me am confused.
You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens if a packages was never rebuild during a devel cycle. And that happens quite often:
[thl@truhe ~]$ lftp -c "open http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/extras/...; ls" > tmpfile [thl@truhe ~]$ wc -l tmpfile 2921 tmpfile [thl@truhe ~]$ grep '.fc6' tmpfile | wc -l 982 [thl@truhe ~]$
Those 982 packages are in my opinion good candidates for not using dist.
Cu thl
On Sat, Apr 07, 2007 at 02:28:20PM +0200, Thorsten Leemhuis wrote:
Those 982 packages are in my opinion good candidates for not using dist.
That's not completly evident. Among those packages there are a lot of arch packages that weren't updated nor rebuilt, yet disttag for those packages are convenient.
-- Pat
Patrice Dumas schrieb:
On Sat, Apr 07, 2007 at 02:28:20PM +0200, Thorsten Leemhuis wrote:
Those 982 packages are in my opinion good candidates for not using dist.
That's not completly evident. Among those packages there are a lot of arch packages that weren't updated nor rebuilt, yet disttag for those packages are convenient.
That why I said "candidates" -- it of course depends on the package itself (maybe it was just a slow devel period upstream with no releases) and the maintainer, if he is willing to take care of some things manually that dists automates.
CU thl
On Sat, Apr 07, 2007 at 03:00:36PM +0200, Thorsten Leemhuis wrote:
Patrice Dumas schrieb:
On Sat, Apr 07, 2007 at 02:28:20PM +0200, Thorsten Leemhuis wrote:
Those 982 packages are in my opinion good candidates for not using dist.
That's not completly evident. Among those packages there are a lot of arch packages that weren't updated nor rebuilt, yet disttag for those packages are convenient.
That why I said "candidates" -- it of course depends on the package itself (maybe it was just a slow devel period upstream with no releases) and the maintainer, if he is willing to take care of some things manually that dists automates.
Anything that may yield different content depending on what release/distro it was built on needs to have a disttag or some other manual package upgrade management function. And even if for some packages the contents did't change between FC6 and F7, they may do so between F7 and F8.
Otherwise indeed, the package should not carry a disttag at all, since it will run the same on FC3 to F10 and RHEL3-RHEL6. But that is seldom the case, even noarch packages like perl and python noarch packages live in different folders across releases.
The fact that there was no mass-rebuild this time for F7 may or may not have a nasty outcome. Just like exim which was "forgotten" [1] to be rebuilt during FC5's release cycle and would have runtime errors (I think due to a changed pam-devel package).
[1] it wasn't forgotten, it was just rebuilt too early and needed another rebuilt.
Le samedi 07 avril 2007 à 14:28 +0200, Thorsten Leemhuis a écrit :
You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens if a packages was never rebuild during a devel cycle. And that happens quite often:
...
Those 982 packages are in my opinion good candidates for not using dist.
/me looks in apache logs, finds repeated PHP warnings and errors, involving (surprise) a core package still bearing the fc6 tag
On 4/7/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/6/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
huh? How is this even physically possible? /me am confused.
You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens if a packages was never rebuild during a devel cycle. And that happens quite often:
So in other words, when the release team branches devel to F7 they don't do a rebuild on all packages like they should?
This seems just a little dangerous to me. All packages should be rebuilt on branches. I am really quite surprised that this is not already done. There are already automatic rebuilding scripts, why not just kick off a shell script?
I would think that checking that a package actually builds before a release would be somewhat important...
Christopher Stone schrieb:
On 4/7/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/6/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
huh? How is this even physically possible? /me am confused.
You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens if a packages was never rebuild during a devel cycle. And that happens quite often:
So in other words, when the release team branches devel to F7 they don't do a rebuild on all packages like they should?
This seems just a little dangerous to me. All packages should be rebuilt on branches.
/me is nor sure if Christopher means the devel branch before or after branching for F7 (in this case).
I am really quite surprised that this is not already done. There are already automatic rebuilding scripts, why not just kick off a shell script?
Because some packagers dislike that? To avoid that users have to download new packages just because they were rebuild? There are probably more reasons that don't come to my mind yet.
Anyway, that stuff in packaging in practice. fedora-devel or fedora-maintainers would thus be the better place to discuss this.
I would think that checking that a package actually builds before a release would be somewhat important...
There are Matt's rebuild efforts. They probably should be integrated into the Fedora infrastructure better. E.g. use the normal builders when they are idle to rebuild packages, check them and if the build fails of something is different then send a mail to the maintainer or automatically open a bug. Or something like that.
CU thl
On 4/9/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/7/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/6/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
huh? How is this even physically possible? /me am confused.
You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens if a packages was never rebuild during a devel cycle. And that happens quite often:
So in other words, when the release team branches devel to F7 they don't do a rebuild on all packages like they should?
This seems just a little dangerous to me. All packages should be rebuilt on branches.
/me is nor sure if Christopher means the devel branch before or after branching for F7 (in this case).
Well, what makes most sense to me is to branch devel to F7. Then do a rebuild on all the packages in F7. This should be done at the time when you freeze stuff (that is only bug fixes go in). This way package maintainers can put big changes in devel and bug fixes in F7.
I am really quite surprised that this is not already done. There are already automatic rebuilding scripts, why not just kick off a shell script?
Because some packagers dislike that? To avoid that users have to download new packages just because they were rebuild? There are probably more reasons that don't come to my mind yet.
Why would you have to download a new package? You arent bumping the release tag or changing the spec file at all. All you are doing is firing off a build of the current package in a new branch. Maintainers have to cvs up -d when new branches take place anyway, so I don't see the issue here.
Anyway, that stuff in packaging in practice. fedora-devel or fedora-maintainers would thus be the better place to discuss this.
I would think that checking that a package actually builds before a release would be somewhat important...
There are Matt's rebuild efforts. They probably should be integrated into the Fedora infrastructure better. E.g. use the normal builders when they are idle to rebuild packages, check them and if the build fails of something is different then send a mail to the maintainer or automatically open a bug. Or something like that.
Indeed, this would be a good idea. I hate searching through the dozens of packages that don't build to try and find one that belongs to me. Much better to automate the process.
Thanks.
Christopher Stone schrieb:
On 4/9/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/7/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/6/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it.
huh? How is this even physically possible? /me am confused.
You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens if a packages was never rebuild during a devel cycle. And that happens quite often:
So in other words, when the release team branches devel to F7 they don't do a rebuild on all packages like they should?
This seems just a little dangerous to me. All packages should be rebuilt on branches.
/me is nor sure if Christopher means the devel branch before or after branching for F7 (in this case).
Well, what makes most sense to me is to branch devel to F7. Then do a rebuild on all the packages in F7. This should be done at the time when you freeze stuff (that is only bug fixes go in). This way package maintainers can put big changes in devel and bug fixes in F7.
devel currently gets branched to F7 when F7 is ready (e.g. the rawhide is (nearly) identical to F7 then). Nobody would want to rebuild everything at that point of time ;-)
So your idea *with the current branching procedure* is a no go.
I am really quite surprised that this is not already done. There are already automatic rebuilding scripts, why not just kick off a shell script?
Because some packagers dislike that? To avoid that users have to download new packages just because they were rebuild? There are probably more reasons that don't come to my mind yet.
Why would you have to download a new package? You arent bumping the release tag or changing the spec file at all. All you are doing is firing off a build of the current package in a new branch.
Example: synaptics-0.14.4-8.fc6 in rawhide and FC-6 now; gets rebuild for F7, so new package is named synaptics-0.14.4-8.fc7. Yum/Anaconda will download and update the new package.
[...]
CU thl
On 4/9/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/9/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/7/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
Christopher Stone schrieb:
On 4/6/07, Thorsten Leemhuis fedora@leemhuis.info wrote: > I also plan to remove disttags from those of my packages that update > seldom, as I think it's just utterly confusing if there are packages in > FC7 that still have a disttag ".fc6" in it. huh? How is this even physically possible? /me am confused.
You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens if a packages was never rebuild during a devel cycle. And that happens quite often:
So in other words, when the release team branches devel to F7 they don't do a rebuild on all packages like they should?
This seems just a little dangerous to me. All packages should be rebuilt on branches.
/me is nor sure if Christopher means the devel branch before or after branching for F7 (in this case).
Well, what makes most sense to me is to branch devel to F7. Then do a rebuild on all the packages in F7. This should be done at the time when you freeze stuff (that is only bug fixes go in). This way package maintainers can put big changes in devel and bug fixes in F7.
devel currently gets branched to F7 when F7 is ready (e.g. the rawhide is (nearly) identical to F7 then). Nobody would want to rebuild everything at that point of time ;-)
So your idea *with the current branching procedure* is a no go.
I am really quite surprised that this is not already done. There are already automatic rebuilding scripts, why not just kick off a shell script?
Because some packagers dislike that? To avoid that users have to download new packages just because they were rebuild? There are probably more reasons that don't come to my mind yet.
Why would you have to download a new package? You arent bumping the release tag or changing the spec file at all. All you are doing is firing off a build of the current package in a new branch.
Example: synaptics-0.14.4-8.fc6 in rawhide and FC-6 now; gets rebuild for F7, so new package is named synaptics-0.14.4-8.fc7. Yum/Anaconda will download and update the new package.
Ah I see. So, what is this yum-presto package I've seen recently and delta rpms? I don't know much about it, but it sounds like a solution to this "problem".
On Monday 09 April 2007 12:55:37 Christopher Stone wrote:
Ah I see. So, what is this yum-presto package I've seen recently and delta rpms? I don't know much about it, but it sounds like a solution to this "problem".
It lessens the problem but doesn't do anything for the amount of processing time needed to process all these needless updates.
On 4/9/07, Jesse Keating jkeating@redhat.com wrote:
On Monday 09 April 2007 12:55:37 Christopher Stone wrote:
Ah I see. So, what is this yum-presto package I've seen recently and delta rpms? I don't know much about it, but it sounds like a solution to this "problem".
It lessens the problem but doesn't do anything for the amount of processing time needed to process all these needless updates.
Checking to see if a package still builds correctly is more important than a little extra processing time during upgrades. I'm pretty sure people expect full upgrades to take a bit of time.
Just my opinoin.
On Monday 09 April 2007 13:13:25 Christopher Stone wrote:
Checking to see if a package still builds correctly is more important than a little extra processing time during upgrades. I'm pretty sure people expect full upgrades to take a bit of time.
Just my opinoin.
What you fail to realize is that you can accomplish checking to see if things build correctly without making those builds go to everybody in the universe as an update. These things are not tied together.
I'm all for continuous rebuild testing, what I'm not for is continuous churning of packages needlessly that users have to consume.
On 4/9/07, Jesse Keating jkeating@redhat.com wrote:
On Monday 09 April 2007 13:13:25 Christopher Stone wrote:
Checking to see if a package still builds correctly is more important than a little extra processing time during upgrades. I'm pretty sure people expect full upgrades to take a bit of time.
Just my opinoin.
What you fail to realize is that you can accomplish checking to see if things build correctly without making those builds go to everybody in the universe as an update. These things are not tied together.
I'm all for continuous rebuild testing, what I'm not for is continuous churning of packages needlessly that users have to consume.
I realize it, I just think you aren't sacrificing much to update dist tags on a new release, so in my opinion you may as well do a rebuild test on the branch itself as part of the release process.
The only semi-official way to upgrade is to download the dvd anyway. And for the people who upgrade via yum, they will have to wait an extra few minutes to download a couple megs of dist tag deltas and headers. Not a very big deal in my opinion.
Just an idea, nothing more. Whether or not you choose to implement it for F8 is ofcourse entirely up to the release team.
Le lundi 09 avril 2007 à 13:18 -0400, Jesse Keating a écrit :
On Monday 09 April 2007 13:13:25 Christopher Stone wrote:
Checking to see if a package still builds correctly is more important than a little extra processing time during upgrades. I'm pretty sure people expect full upgrades to take a bit of time.
Just my opinoin.
What you fail to realize is that you can accomplish checking to see if things build correctly without making those builds go to everybody in the universe as an update. These things are not tied together.
But you can't accomplish checking the maintainer did check the package builds and works with the rest of a release if you allow old release packages
Sorry, but "it builds" is not a good check. Especially if no human ever runs the result
On Mon, Apr 09, 2007 at 08:49:48PM +0200, Nicolas Mailhot wrote:
Le lundi 09 avril 2007 à 13:18 -0400, Jesse Keating a écrit :
On Monday 09 April 2007 13:13:25 Christopher Stone wrote:
Checking to see if a package still builds correctly is more important than a little extra processing time during upgrades. I'm pretty sure people expect full upgrades to take a bit of time.
Just my opinoin.
What you fail to realize is that you can accomplish checking to see if things build correctly without making those builds go to everybody in the universe as an update. These things are not tied together.
But you can't accomplish checking the maintainer did check the package builds and works with the rest of a release if you allow old release packages
Sorry, but "it builds" is not a good check. Especially if no human ever runs the result
I agree with Nicolas, at least one test release should be used to rebuild everything in rawhide and have thus the result tested.
On 09.04.2007 22:57, Axel Thimm wrote:
On Mon, Apr 09, 2007 at 08:49:48PM +0200, Nicolas Mailhot wrote:
Le lundi 09 avril 2007 à 13:18 -0400, Jesse Keating a écrit :
On Monday 09 April 2007 13:13:25 Christopher Stone wrote:
Checking to see if a package still builds correctly is more important than a little extra processing time during upgrades. I'm pretty sure people expect full upgrades to take a bit of time. Just my opinoin.
What you fail to realize is that you can accomplish checking to see if things build correctly without making those builds go to everybody in the universe as an update. These things are not tied together.
But you can't accomplish checking the maintainer did check the package builds and works with the rest of a release if you allow old release packages Sorry, but "it builds" is not a good check. Especially if no human ever runs the result
I agree with Nicolas, at least one test release should be used to rebuild everything in rawhide and have thus the result tested.
I kind of agree with you two that testing the freshly build packages would be best. But *I* think not rebuilding everything when there is no need to is more important, because
- the existing packages are out in the wild and we know that those work well
- we seem to have users in countries were internet bandwidth seems to be costly and unreliable. We make it a lot easier for those people if we don't force them to download and update new packages that were rebuild without real improvements
The compromise that IMHO should makes both sides happy: we have mass-rebuilds quite often anyway (probably every two or three releases due to toolchain changes; e.g. once a year). We rebuild and test everything then in any case anyway and that IMHO should be sufficient -- so lets skip releases like F7.
CU thl
On Tue, Apr 10, 2007 at 06:53:05AM +0200, Thorsten Leemhuis wrote:
On 09.04.2007 22:57, Axel Thimm wrote:
On Mon, Apr 09, 2007 at 08:49:48PM +0200, Nicolas Mailhot wrote:
Le lundi 09 avril 2007 à 13:18 -0400, Jesse Keating a écrit :
On Monday 09 April 2007 13:13:25 Christopher Stone wrote:
Checking to see if a package still builds correctly is more important than a little extra processing time during upgrades. I'm pretty sure people expect full upgrades to take a bit of time. Just my opinoin.
What you fail to realize is that you can accomplish checking to see if things build correctly without making those builds go to everybody in the universe as an update. These things are not tied together.
But you can't accomplish checking the maintainer did check the package builds and works with the rest of a release if you allow old release packages Sorry, but "it builds" is not a good check. Especially if no human ever runs the result
I agree with Nicolas, at least one test release should be used to rebuild everything in rawhide and have thus the result tested.
I kind of agree with you two that testing the freshly build packages would be best. But *I* think not rebuilding everything when there is no need to is more important, because
- the existing packages are out in the wild and we know that those work well
I've seen this argument twice now and I think it's both faulty and dangerous: How can you consider packages to be "stable" when there is fear that simply rebuilding them in a different environment will break them, especially when this environment is the one the release is defined with?
These are exactly the fragile packages we're after and don't want to wave into the release w/o a fix. Currently we're running into the release with closed eyes.
- we seem to have users in countries were internet bandwidth seems to be
costly and unreliable. We make it a lot easier for those people if we don't force them to download and update new packages that were rebuild without real improvements
Check out what the real space consumers are, openoffice, glibc and kernels - these always get rebuilt per release. The next rows with libstdc++, kdebase or the Mozilla projects do so as well. As a matter of fact if counted in size almost everything on the CD/DVD spins in the test releases has been rebuilt.
So there is no real win here.
The compromise that IMHO should makes both sides happy: we have mass-rebuilds quite often anyway (probably every two or three releases due to toolchain changes; e.g. once a year).
No, that's not the truth, we had them for every release until now, only F7 got skipped. Check the repo if you can't remember.
On Tuesday 10 April 2007 02:55:47 Axel Thimm wrote:
No, that's not the truth, we had them for every release until now, only F7 got skipped. Check the repo if you can't remember.
We haven't on core side. We've done targetted rebuilds of things for specific changes, not every single package. Many noarch packages were not rebuilt for a period of time. With FC6 we rebuilt every package that hadn't yet been built by our new buildsystem, as well as any compiled package that wasn't compiled with the new gcc.
On Tue, Apr 10, 2007 at 08:48:44AM -0400, Jesse Keating wrote:
No, that's not the truth, we had them for every release until now, only F7 got skipped. Check the repo if you can't remember.
We haven't on core side. We've done targetted rebuilds of things for specific changes, not every single package. Many noarch packages were not rebuilt for
Yes, this is certainly true, because I've often encountered packages that don't actually rebuild anymore, or worse, rebuild, but act entirely differently. The latter is particularly what I want to avoid. I think we should force-rebuild all packages somewhere in the middle of the development cycle.
On Tue, 2007-04-10 at 09:05 -0400, Matthew Miller wrote:
On Tue, Apr 10, 2007 at 08:48:44AM -0400, Jesse Keating wrote:
No, that's not the truth, we had them for every release until now, only F7 got skipped. Check the repo if you can't remember.
We haven't on core side. We've done targetted rebuilds of things for specific changes, not every single package. Many noarch packages were not rebuilt for
Yes, this is certainly true, because I've often encountered packages that don't actually rebuild anymore, or worse, rebuild, but act entirely differently. The latter is particularly what I want to avoid. I think we should force-rebuild all packages somewhere in the middle of the development cycle.
There is no guarantee that a rebuild in the middle of the development cycle magically makes the packages rebuildable all the way through the final release.
On Tuesday 10 April 2007 09:12:03 Matthias Clasen wrote:
Yes, this is certainly true, because I've often encountered packages that don't actually rebuild anymore, or worse, rebuild, but act entirely differently. The latter is particularly what I want to avoid. I think we should force-rebuild all packages somewhere in the middle of the development cycle.
There is no guarantee that a rebuild in the middle of the development cycle magically makes the packages rebuildable all the way through the final release.
Exactly. It's a false sense of security. Actually looking at the continuous rebuild reports and diffing the package sets or maybe even doing some automated testing with them is the only way to know. And hey, automated testing of package functionality is a good thing, whether done at an automatic throwaway rebuild time or done when a change is introduced into the live package set. Just rebuilding everything at an arbitrary time and hoping for the best is not a solution.
On Tue, Apr 10, 2007 at 03:12:03PM +0200, Matthias Clasen wrote:
Yes, this is certainly true, because I've often encountered packages that don't actually rebuild anymore, or worse, rebuild, but act entirely differently. The latter is particularly what I want to avoid. I think we should force-rebuild all packages somewhere in the middle of the development cycle.
There is no guarantee that a rebuild in the middle of the development cycle magically makes the packages rebuildable all the way through the final release.
That's true. It'll certainly *help*, though.
On Tue, Apr 10, 2007 at 09:05:26AM -0400, Matthew Miller wrote:
On Tue, Apr 10, 2007 at 08:48:44AM -0400, Jesse Keating wrote:
No, that's not the truth, we had them for every release until now, only F7 got skipped. Check the repo if you can't remember.
We haven't on core side. We've done targetted rebuilds of things for specific changes, not every single package. Many noarch packages were not rebuilt for
Yes, this is certainly true, because I've often encountered packages that don't actually rebuild anymore, or worse, rebuild, but act entirely differently. The latter is particularly what I want to avoid. I think we should force-rebuild all packages somewhere in the middle of the development cycle.
Well, not in the middle, but after the feature freeze. That way anything that blows up wither at build or run time gets fixed while the freeze ensures API/ABI stability (w/ exceptions, of course, but these get handled specially anyway)
On Tue, Apr 10, 2007 at 08:48:44AM -0400, Jesse Keating wrote:
On Tuesday 10 April 2007 02:55:47 Axel Thimm wrote:
No, that's not the truth, we had them for every release until now, only F7 got skipped. Check the repo if you can't remember.
We haven't on core side.
It depends on what you call a full rebuild. The core side has always rebuilt >= 95% of all packages, most release much more than 99%. I would call that very close to a full rebuild.
Here are the numbers of the amount of Core packages rebuilt per release. FC1 gets 100% because I don't have the RHL9 packages handy, but anyway (for > 99% I added as many digits as neccessary to show what wasn't rebuilt):
1 100% 2 99.7% 3 100% 4 96.6% 5 99.991% 6 95% 7 80%
So as you see, up to F7 Core had really been effectively rebuilt on each release with FC4 and FC5 being the most "sloppy" ones leaving 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% rebuild rate. This *is* a new release model.
Just looking at what hasn't been requilt: Some packages like bitstream-fonts really don't deserve a rebuild (they also don't deserve a disttag FWIW), but others like bridge-utils that depend on kernel-headers at build time possibly do, and now we're running with bridge-utils built against 2.6.18.
Instead of checking each package whether it should be rebuilt or not, it is easier, faster and correcter to do a full rebuild at release freezing time in the development cycle.
We've done targetted rebuilds of things for specific changes, not every single package. Many noarch packages were not rebuilt for a period of time. With FC6 we rebuilt every package that hadn't yet been built by our new buildsystem, as well as any compiled package that wasn't compiled with the new gcc.
Check the repos, you'll find the same numbers I wrote above.
On Tuesday 10 April 2007 09:33:29 Axel Thimm wrote:
1 100% 2 99.7% 3 100% 4 96.6% 5 99.991% 6 95% 7 80%
So as you see, up to F7 Core had really been effectively rebuilt on each release with FC4 and FC5 being the most "sloppy" ones leaving 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% rebuild rate. This *is* a new release model.
What I'm saying is that these numbers often happen naturally instead of forced by a full rebuild. _That_ is the model that hasn't changed. The ONLY time we've done a forced rebuild is for technical reasons and NOT for arbitrary reasons like "hrm, this is test2, maybe we should rebuild everything just for the hell of it" or "there is a lot of disttags that haven't been updated, lets do rebuilds to reset them, that sounds like a good idea...".
Rebuilding for technical reasons is fine, relying upon throwaway rebuilds to find said technical reasons is strongly encouraged. Picking arbitrary points to forcefully rebuild everything is not.
On Tue, Apr 10, 2007 at 10:41:07AM -0400, Jesse Keating wrote:
On Tuesday 10 April 2007 09:33:29 Axel Thimm wrote:
1 100% 2 99.7% 3 100% 4 96.6% 5 99.991% 6 95% 7 80%
So as you see, up to F7 Core had really been effectively rebuilt on each release with FC4 and FC5 being the most "sloppy" ones leaving 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% rebuild rate. This *is* a new release model.
What I'm saying is that these numbers often happen naturally instead of forced by a full rebuild. _That_ is the model that hasn't changed.
OK, still the packages were all more or less rebuilt, and sometimes the packagers comment this as a simple rebuild for the upcoming release. Which means that while there was no mass-rebuild, many packagers in RH decided to do so on their own when the time came.
For F7 the policy obviously changed, otherwise there wouldn't be a sudden drop from 95-100% to 80%.
The ONLY time we've done a forced rebuild is for technical reasons and NOT for arbitrary reasons like "hrm, this is test2, maybe we should rebuild everything just for the hell of it" or "there is a lot of disttags that haven't been updated, lets do rebuilds to reset them, that sounds like a good idea...".
Forget about the disttags, the discussion started about them, but this is not about cosmetics. They only indicate the problem which is that some packages have not been rebuilt. I'm personally against rebuilding just for the fun of nice disttags.
But I'm all for rebuilding where it makes a technical difference. Some userland utils depend on kernel-headers, that has changed and in doubt all such dependent packages would require rebuilds or a review. Furthermore glibc has changed in various places among other some sys/personality stuff and kernel 2.4->2.6 bits. Any package that required 2.4 compatibility in this area is now busted (don't remember whether it was sys/personality or something else, check the diff). And who's going to check which packages where using these glibc headers to enforce a per-package rebuild?
And this is just the surface scratched. If someone invests more time, he will come up with more dependencies that may now be broken or not, and finding that out takes more developers' time than a simple rebuild-all-and-test-the-outcome model.
Rebuilding for technical reasons is fine, relying upon throwaway rebuilds to find said technical reasons is strongly encouraged.
Ask yourself why they are being thrown away. If there really is no technical reason to rebuild a package, then the rebuilt package can't be broken or less stable that the "old" one. By throwing them away you never have the chance to actually have them tested by a wider audience (or any audience at all). Placing the rebuilds into rawhide instead will really show whether the rebuild was worth it or not, e.g. when things start to break, and you get a change in fixing them.
Now we will only get that chance when a package is rebuilt for other reasons post-release, e.g. while adding a security fix. And imagine the confusion of the packager that only changed one line in foo-1.2-3.fc6, successfully rebuilt it to foo-1.2-4.fc7, and the package does not run. Because that scenarion will happen, Matt checks for build errors, so the build will succeed, but the more intricate runtime bugs will only surface when you have the least time to deal with them. And the horror scenario is that since it was a one-liner fix it will get less testing and make it into updates-released being half-broken giving Fedora negative publicity.
In short: It's better to have these packages break and fix them during the development/testing cycle than during maintenance.
Picking arbitrary points to forcefully rebuild everything is not.
Not an arbitrary point, but at "freeze time" (personally I would rebuild for each test release, but rebuilding once at freeze time would be enough).
And again: This has nothing to do with rectifying disttags and cosmetics in the package name, they are for now just an easy metric to see what was rebuilt, and when. And if we'd decide to go for full rebuilds, disttags would be a tool to get 98% done w/o a sweat. But still they are not the problem, they might become the solution instead.
On Tue, 2007-04-10 at 15:33 +0200, Axel Thimm wrote:
Just looking at what hasn't been requilt: Some packages like bitstream-fonts really don't deserve a rebuild (they also don't deserve a disttag FWIW), but others like bridge-utils that depend on kernel-headers at build time possibly do, and now we're running with bridge-utils built against 2.6.18.
But see, just rebuilding bridge-utils isn't going to be enough to get any new kernel functionality[1]... you also going to want to get the new release of bridge-utils. And go through any bugs filed.
Automated rebuilds tend to hide things like this, which actually lead to more problems down the line
Jeremy
[1] I don't know if there actually _is_ any in this case, but there is a new bridge-utils upstream release from a quick look at the website.
On Tue, Apr 10, 2007 at 10:41:53AM -0400, Jeremy Katz wrote:
On Tue, 2007-04-10 at 15:33 +0200, Axel Thimm wrote:
Just looking at what hasn't been requilt: Some packages like bitstream-fonts really don't deserve a rebuild (they also don't deserve a disttag FWIW), but others like bridge-utils that depend on kernel-headers at build time possibly do, and now we're running with bridge-utils built against 2.6.18.
But see, just rebuilding bridge-utils isn't going to be enough to get any new kernel functionality[1]... you also going to want to get the new release of bridge-utils. And go through any bugs filed.
I'm not after *new* functionality, I'm afraid bridge-utils build on possibly deprecated functionality. Maybe bridge-utils requires some love, maybe not, we won't know until someone either review the case or does a rebuild.
Automated rebuilds tend to hide things like this, which actually lead to more problems down the line
Jeremy
[1] I don't know if there actually _is_ any in this case, but there is a new bridge-utils upstream release from a quick look at the website.
That was just an example, I only looked `till the letter "b" and found bitstream and bridge-utils as two opposite examples (one not worth of rebuilds, one the probably is).
The point I want to make is that it is easier to do the rebuild and see if something breaks while building and/or running it, than to let it degrade in time and be bitten by it when you least expect it.
I don't think automated rebuild would hide any issues, in fact on the contrary, they would expose any issues in our faces, *IFF* the get committed into rawhide proper.
That's why I think that the test release tagged "frozen" should be a complete rebuild.
On Tuesday 10 April 2007 11:00:23 Axel Thimm wrote:
That's why I think that the test release tagged "frozen" should be a complete rebuild.
Which would mean starting our QA all over again and throwing out any results up to date. Wrong answer. And this conversation really belongs elsewhere, it isn't a packaging issue.
On Tue, Apr 10, 2007 at 11:12:34AM -0400, Jesse Keating wrote:
On Tuesday 10 April 2007 11:00:23 Axel Thimm wrote:
That's why I think that the test release tagged "frozen" should be a complete rebuild.
Which would mean starting our QA all over again and throwing out any results up to date. Wrong answer.
Well, FWIW it wasn't the wrong answer for so many releases, and as outlined previously you're pushing the hard bits from the development cycle to the maintenance one. Let's hope we're lucky.
And this conversation really belongs elsewhere, it isn't a packaging issue.
I agree, but it wasn't me who turned this into a rebuild thread.
On Monday 09 April 2007 12:12:18 Christopher Stone wrote:
Why would you have to download a new package? You arent bumping the release tag or changing the spec file at all. All you are doing is firing off a build of the current package in a new branch. Maintainers have to cvs up -d when new branches take place anyway, so I don't see the issue here.
Yet, the disttag WOULD get bumped and everybody would have to download this package as an update just to get the new dist tag.
On Fri, Apr 06, 2007 at 06:29:36PM +0200, Patrice Dumas wrote:
On Fri, Apr 06, 2007 at 06:04:56PM +0200, Axel Thimm wrote:
Hi,
o continue suggesting the use of disttags to new packagers - even though optional it should be the recommended way to package things up.
But remember that for data noarch packages, and software noarch packages that don't in stall in versionned interpreter directory disttages are harmfull.
I agree, in general anything that wouldn't change from release to release, for example because it just get's installed w/o any processing onto the filesystem should not carry a disttag but be shared as a single instance. Firmwares and content packages come to mind.
In fact if we ever (e.g. at F8 release time) decide on making disttag mandatory, we would have to exclude these packages from carrying a disttag and would have thus a handle of identifying cross-distribution/cross-release packages.
I though there was something in the wiki about that but I can't find it.
On Fri, 06 Apr 2007 18:04:56 +0200, Axel Thimm wrote:
Conclusions:
o The disttag idiom was very successful, even though it is not mandatory it managed to be adopted in over 98% of Fedora Extras and 69% of Fedora Core.
I'd just like say, I'd have never used disttags if I wasn't forced to.
There was some errors I was getting in trying to commit and build some package and the "recommendation" was to just use disttags. That worked so I never really thought about it since then.
So for my case, it didn't really offer anything for me that makes it a "success"; just something I had to do to get my packages to continue through the build system.
packaging@lists.fedoraproject.org