[gentoo-dev] Usage of cp -i to prevent overwriting upstream files
Many times upstream Java projects don't include build.xml files or proper build systems so we include build.xml files in $FILESDIR. In case upstream some day adds one we usually use cp -i to detect if upstream adds this file in new versions. If devs do their job properly, this will never show to users. On #gentoo-dev at least grobian and darkside did not like this and proposed using test and die instead. If we think that cp -i is not acceptable, this should be made a function to avoid code duplication in my opinion. Here's a suggestion: function cp-no-replace() { debug-print-function ${FUNCNAME} $* [[ ${#} != 2 ]] die ${FUNCNAME} takes two arguments [[ -e ${2} ]] die die target exists cp ${1} ${2} || die cp failed } So do you think: a) cp -i is fine b) this function should be added to eutils c) keep it restricted to java eclasses d) something else Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
On Tue, 2009-01-20 at 21:04 +0200, Petteri Räty wrote: Many times upstream Java projects don't include build.xml files or proper build systems so we include build.xml files in $FILESDIR. In case upstream some day adds one we usually use cp -i to detect if upstream adds this file in new versions. If devs do their job properly, this will never show to users. On #gentoo-dev at least grobian and darkside did not like this and proposed using test and die instead. If we think that cp -i is not acceptable, this should be made a function to avoid code duplication in my opinion. Here's a suggestion: function cp-no-replace() { debug-print-function ${FUNCNAME} $* [[ ${#} != 2 ]] die ${FUNCNAME} takes two arguments [[ -e ${2} ]] die die target exists cp ${1} ${2} || die cp failed } So do you think: a) cp -i is fine Fine with me b) this function should be added to eutils I don't like this one --- [[ ${#} != 2 ]] die ${FUNCNAME} takes two arguments [[ -e ${2} ]] die die target exists How does the user recover from that? I would become irate if a build died without giving some useful indication the problem. c) keep it restricted to java eclasses d) something else Regards, Petteri Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
Ferris McCormick wrote: On Tue, 2009-01-20 at 21:04 +0200, Petteri Räty wrote: Many times upstream Java projects don't include build.xml files or proper build systems so we include build.xml files in $FILESDIR. In case upstream some day adds one we usually use cp -i to detect if upstream adds this file in new versions. If devs do their job properly, this will never show to users. On #gentoo-dev at least grobian and darkside did not like this and proposed using test and die instead. If we think that cp -i is not acceptable, this should be made a function to avoid code duplication in my opinion. Here's a suggestion: function cp-no-replace() { debug-print-function ${FUNCNAME} $* [[ ${#} != 2 ]] die ${FUNCNAME} takes two arguments [[ -e ${2} ]] die die target exists cp ${1} ${2} || die cp failed } So do you think: a) cp -i is fine Fine with me b) this function should be added to eutils I don't like this one --- [[ ${#} != 2 ]] die ${FUNCNAME} takes two arguments [[ -e ${2} ]] die die target exists How does the user recover from that? I would become irate if a build died without giving some useful indication the problem. You did not understand the issue if you are fine with a) but then make this statement. a) would surely be even more confusing to the user. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
On Tue, 2009-01-20 at 21:37 +0200, Petteri Räty wrote: Ferris McCormick wrote: On Tue, 2009-01-20 at 21:04 +0200, Petteri Räty wrote: Many times upstream Java projects don't include build.xml files or proper build systems so we include build.xml files in $FILESDIR. In case upstream some day adds one we usually use cp -i to detect if upstream adds this file in new versions. If devs do their job properly, this will never show to users. On #gentoo-dev at least grobian and darkside did not like this and proposed using test and die instead. If we think that cp -i is not acceptable, this should be made a function to avoid code duplication in my opinion. Here's a suggestion: function cp-no-replace() { debug-print-function ${FUNCNAME} $* [[ ${#} != 2 ]] die ${FUNCNAME} takes two arguments [[ -e ${2} ]] die die target exists cp ${1} ${2} || die cp failed } So do you think: a) cp -i is fine Fine with me b) this function should be added to eutils I don't like this one --- [[ ${#} != 2 ]] die ${FUNCNAME} takes two arguments [[ -e ${2} ]] die die target exists How does the user recover from that? I would become irate if a build died without giving some useful indication the problem. You did not understand the issue if you are fine with a) but then make this statement. a) would surely be even more confusing to the user. Regards, Petteri I think I understand the issue. My point is that die die target exists gives no clue whatsoever as to what to do or where the problem is and strikes me as something that should never appear in a proper build. If that's the preferred solution, at least indicate that the ebuild has not caught up with upstream and that the user is not at fault. 'cp -i' will at least ask a question, and I find that marginally better --- it's confusing, but at least it says something. But it seems to me that if we hit this case, no one (including the package owner) knows which .xml file to use, so stopping the build makes sense, but do it with some message that explains exactly what is going on. I do not intend to respond further to this thread. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
Ferris McCormick wrote: 'cp -i' will at least ask a question, and I find that marginally better --- it's confusing, but at least it says something. But it seems to me that if we hit this case, no one (including the package owner) knows which .xml file to use, so stopping the build makes sense, but do it with some message that explains exactly what is going on. The problem is that the whole build won't *abort*, but rather become interactive. I for one think that having it die (in the unlikely case that s developer made a mistake) is better than letting it hang indefinitely (in the unlikely case that a developer made a mistake) :). Think about insane users setting up cronjobs and what not... Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
On Tue, 20 Jan 2009 23:50:47 +0100 Jan Kundrát j...@gentoo.org wrote: Ferris McCormick wrote: 'cp -i' will at least ask a question, and I find that marginally better --- it's confusing, but at least it says something. But it seems to me that if we hit this case, no one (including the package owner) knows which .xml file to use, so stopping the build makes sense, but do it with some message that explains exactly what is going on. The problem is that the whole build won't *abort*, but rather become interactive. I for one think that having it die (in the unlikely case that s developer made a mistake) is better than letting it hang indefinitely (in the unlikely case that a developer made a mistake) :). That's what I meant by stopping the build. My concern is that when we do stop the build, we do it with some useful error message and make it clear that the user did not screw up and so should do something to fix it. (die file exists looks to me like an attempt to ask the user to fix something, not an ebuild problem.) As I think about it, I am not sure how this could happen. It would either be an ebuild that the package owner never tried or a change in the source file. And why wouldn't a change in the source file cause an immediate termination because the length would suddenly be wrong? And if the now-upstream-supplied build.xml file is different from the one the developer put together, wouldn't you probably want a revision bump at that point? Think about insane users setting up cronjobs and what not... Cheers, -jkt -- cd /local/pub more beer /dev/mouth Clearly, I misspoke when I said I'd not respond further. :) Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files
On Tue, Jan 20, 2009 at 5:40 PM, Ferris McCormick fmc...@gentoo.org wrote: On Tue, 20 Jan 2009 23:50:47 +0100 Jan Kundrát j...@gentoo.org wrote: Ferris McCormick wrote: 'cp -i' will at least ask a question, and I find that marginally better --- it's confusing, but at least it says something. But it seems to me that if we hit this case, no one (including the package owner) knows which .xml file to use, so stopping the build makes sense, but do it with some message that explains exactly what is going on. The problem is that the whole build won't *abort*, but rather become interactive. I for one think that having it die (in the unlikely case that s developer made a mistake) is better than letting it hang indefinitely (in the unlikely case that a developer made a mistake) :). That's what I meant by stopping the build. My concern is that when we do stop the build, we do it with some useful error message and make it clear that the user did not screw up and so should do something to fix it. (die file exists looks to me like an attempt to ask the user to fix something, not an ebuild problem.) Sure. Makes sense. As I think about it, I am not sure how this could happen. It would either be an ebuild that the package owner never tried or a change in the source file. And why wouldn't a change in the source file cause an immediate termination because the length would suddenly be wrong? And Regardless of *how* it happens, my only point is to not put any interactiveness in ebuilds for *whatever* reason. If it does prompt for a response (again, for whatever reason) then all of portage's background features are broke (waiting for input). So, as I suggested in irc, the two solutions are to use the suggested method in the OP or to set PROPERTIES=interactive in the ebuild..either way will work. I would personally avoid the properties route on ebuilds that I write though because it doesn't *need* to be interactive. -Jeremy if the now-upstream-supplied build.xml file is different from the one the developer put together, wouldn't you probably want a revision bump at that point? Think about insane users setting up cronjobs and what not... Cheers, -jkt -- cd /local/pub more beer /dev/mouth Clearly, I misspoke when I said I'd not respond further. :) Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees)
[gentoo-dev] Why recently published stage3 tarball did not contain a /etc/make.conf.example?
Why recently published stage3 tarball did not contain a /etc/make.conf.example? http://distfiles.gentoo.org/experimental/amd64/autobuilds/20090115/stage3-amd64-20090115.tar.bz2 but the /etc/make.conf said: # Please consult /etc/make.conf.example for a more detailed example. If plan to remove that example file, why still keep this comment? Thanks, -- Cheng Renquan, Shenzhen, China Emo Philips - I was sleeping the other night, alone, thanks to the exterminator.
Re: [gentoo-dev] Why recently published stage3 tarball did not contain a /etc/make.conf.example?
Cheng Renquan wrote: Why recently published stage3 tarball did not contain a /etc/make.conf.example? http://distfiles.gentoo.org/experimental/amd64/autobuilds/20090115/stage3-amd64-20090115.tar.bz2 but the /etc/make.conf said: # Please consult /etc/make.conf.example for a more detailed example. If plan to remove that example file, why still keep this comment? The file is provided by portage, and the installed location was changed recently to /usr/share/portage/config/make.conf.example. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] Why recently published stage3 tarball did not contain a /etc/make.conf.example?
On Wed, Jan 21, 2009 at 11:23 AM, Andrew Gaffney agaff...@gentoo.org wrote: Cheng Renquan wrote: Why recently published stage3 tarball did not contain a /etc/make.conf.example? http://distfiles.gentoo.org/experimental/amd64/autobuilds/20090115/stage3-amd64-20090115.tar.bz2 but the /etc/make.conf said: # Please consult /etc/make.conf.example for a more detailed example. If plan to remove that example file, why still keep this comment? The file is provided by portage, and the installed location was changed recently to /usr/share/portage/config/make.conf.example. So then that comment in /etc/make.conf should be fixed? Thanks. -- Cheng Renquan, Shenzhen, China Katharine Hepburn - Death will be a great relief. No more interviews.
Re: [gentoo-dev] Why recently published stage3 tarball did not contain a /etc/make.conf.example?
Cheng Renquan wrote: On Wed, Jan 21, 2009 at 11:23 AM, Andrew Gaffney agaff...@gentoo.org wrote: Cheng Renquan wrote: Why recently published stage3 tarball did not contain a /etc/make.conf.example? http://distfiles.gentoo.org/experimental/amd64/autobuilds/20090115/stage3-amd64-20090115.tar.bz2 but the /etc/make.conf said: # Please consult /etc/make.conf.example for a more detailed example. If plan to remove that example file, why still keep this comment? The file is provided by portage, and the installed location was changed recently to /usr/share/portage/config/make.conf.example. So then that comment in /etc/make.conf should be fixed? Thanks. I've already made this change in catalyst git, but there is no new release with it. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead