[opensuse-buildservice] Automatically package a new upstream version
Hi, While writing my previous mail, I started thinking: if the build service knows about a new upstream version, maybe there could be a link that tries to automatically update the package to the new upstream version. It would download the tarball, checks the md5 sum (if we specify an URL where it can be found), update Version and Release in the spec file and add an entry to the changes file. It would certainly not work in many cases because of some patches, or changes in the dependencies or for a tons of other reasons. But it would still work in a lot of cases, wouldn't it? Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello!
It would certainly not work in many cases because of some patches, or changes in the dependencies or for a tons of other reasons. But it would still work in a lot of cases, wouldn't it?
Unfortunately, although your idea seems great, the problem seems to be very difficult. I have an experience with much simpler task: update automagically just a small and quite uniform part of our distribution, perl modules. And while most of my work is actually done by my update scripts, I still have to manually and pretty carefully check every single package. First problem: We have a lots of patches in our packages. Ideally, every single patch should be checked during an update because although it might apply correctly, it could make no sense anymore or even do some harm. (Upstream can address the same issue in a very different way than us.) Second problem: Testing. While perl modules have usually great testcases and when they build, you can be quite sure they are working, most of other packages cannot be tested that easily. My experience says that cases when the package compiles but does not test are very frequent. As we do not want broken packages, we would have to write a testsuite, that is able to run automatically, for every single package. And third: Although it sounds funny, it is very difficult to produce a RPM changelog from an upstream changelog automatically. Changelogs have various formats and even if authors stick to their choice strictly and you know them all, you probably cannot even distinguish them automatically. Anicka --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Le lundi 17 mars 2008, à 11:57 +0100, Anicka Bernathova a écrit :
Hello!
It would certainly not work in many cases because of some patches, or changes in the dependencies or for a tons of other reasons. But it would still work in a lot of cases, wouldn't it?
Unfortunately, although your idea seems great, the problem seems to be very difficult. I have an experience with much simpler task: update automagically just a small and quite uniform part of our distribution, perl modules. And while most of my work is actually done by my update scripts, I still have to manually and pretty carefully check every single package.
First problem: We have a lots of patches in our packages. Ideally, every single patch should be checked during an update because although it might apply correctly, it could make no sense anymore or even do some harm. (Upstream can address the same issue in a very different way than us.)
Yep, that's one case where it wouldn't work.
Second problem: Testing. While perl modules have usually great testcases and when they build, you can be quite sure they are working, most of other packages cannot be tested that easily. My experience says that cases when the package compiles but does not test are very frequent. As we do not want broken packages, we would have to write a testsuite, that is able to run automatically, for every single package.
Agree.
And third: Although it sounds funny, it is very difficult to produce a RPM changelog from an upstream changelog automatically. Changelogs have various formats and even if authors stick to their choice strictly and you know them all, you probably cannot even distinguish them automatically.
Ah, totally forgot this, yes. The script I quickly wrote to update packages still forces me to do this manually, indeed. Oh well, not a big problem. Sounded neat, but I understand it might not be possible... Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
hi you might be interested in http://en.opensuse.org/Build_Service/Upstream_Integration darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, 2008-03-17 at 11:57 +0100, Anicka Bernathova wrote:
Hello!
It would certainly not work in many cases because of some patches, or changes in the dependencies or for a tons of other reasons. But it would still work in a lot of cases, wouldn't it?
Unfortunately, although your idea seems great, the problem seems to be very difficult. I have an experience with much simpler task: update automagically just a small and quite uniform part of our distribution, perl modules. And while most of my work is actually done by my update scripts, I still have to manually and pretty carefully check every single package.
First problem: We have a lots of patches in our packages. Ideally, every single patch should be checked during an update because although it might apply correctly, it could make no sense anymore or even do some harm. (Upstream can address the same issue in a very different way than us.)
that's why we need to be more active in upstreaming patches. We have packages with an insane amount of patches, most of them fixing just small problems which will be, even if after some modification, accepted upstream. That's what we are trying to do on the GNOME part (http://en.opensuse.org/GNOME/Projects/PatchUpstreaming), but it would be great if the whole distro did the same. Then, Vincent's idea would be much easier to implement correctly Of course, we'll always have to review the resulting package, but in lots of cases (packages with no patches or with very simple patches) it would just work.
Second problem: Testing. While perl modules have usually great testcases and when they build, you can be quite sure they are working, most of other packages cannot be tested that easily. My experience says that cases when the package compiles but does not test are very frequent. As we do not want broken packages, we would have to write a testsuite, that is able to run automatically, for every single package.
And third: Although it sounds funny, it is very difficult to produce a RPM changelog from an upstream changelog automatically. Changelogs have various formats and even if authors stick to their choice strictly and you know them all, you probably cannot even distinguish them automatically.
we could use the NEWS files, although again, not all upstream projects
use it :-(
--
Rodrigo Moya
that's why we need to be more active in upstreaming patches. We have packages with an insane amount of patches, most of them fixing just small problems which will be, even if after some modification, accepted upstream. That's what we are trying to do on the GNOME part (http://en.opensuse.org/GNOME/Projects/PatchUpstreaming), but it would be great if the whole distro did the same. Then, Vincent's idea would be much easier to implement correctly
I believe that all of us are doing our best in upstreaming our patches. Unfortunately, there are many situations, when it cannot be done - upstream is dead, upstream has another opinion, process takes very long, our patch is SUSE-specific, our patch just workarounds some nasty bug that no one can fix... Yes, we should upstream as much as possible. But I am pretty sure that even then we will have loads of patches. And I do not think that automatical update that does not work on any of the more important packages is really helpful. Anicka --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Anicka,
I believe that all of us are doing our best in upstreaming our patches. Unfortunately, there are many situations, when it cannot be done - upstream is dead, upstream has another opinion, process takes very long, our patch is SUSE-specific, our patch just workarounds some nasty bug that no one can fix...
Yes, we should upstream as much as possible. But I am pretty sure that even then we will have loads of patches. And I do not think that automatic update that does not work on any of the more important packages is really helpful.
I appreciate your candor in this matter, however I've been on the other end of this attitude in the past. I'm the maintainer of the openslp project. I found out one day several years ago that SuSE had several patches that would have been nice to have in the main code base, but no one bothered to tell me that they even existed. Perhaps it would be good for the community in general to have distro packagers simply contact package maintainers through associated devel mailing lists. A quick note on the list to say that the package has been picked up by a distro, and that patches would be available at a specific location. Then the packager wouldn't be committed to a long-term relationship. The maintainer could check once in a while to see what's out there. John --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Anicka Bernathova -
John Calcote -
Marcus Rueckert -
Rodrigo Moya -
Vincent Untz