[gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Ferris McCormick]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

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) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Ferris McCormick]

[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]

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) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Ferris McCormick]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On Tue, 20 Jan 2009 23:50:47 +0100
Jan Kundrát <jkt@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) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Jeremy Olexa]

On Tue, Jan 20, 2009 at 5:40 PM, Ferris McCormick <fmccor@gentoo.org> wrote:
> On Tue, 20 Jan 2009 23:50:47 +0100
> Jan Kundrát <jkt@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) <fmccor@gentoo.org>
> Developer, Gentoo Linux (Sparc, Userrel, Trustees)
>

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

В Втр, 20/01/2009 в 21:04 +0200, Petteri Räty пишет:
> So do you think:
> a) cp -i is fine

No, interactivity is bad.

> b) this function should be added to eutils
> c) keep it restricted to java eclasses

I don't remember/know any other cases where this function can be useful.
So I think it's better to add it somewhere into java eclasses.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Santiago M. Mola]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

El mar, 20-01-2009 a las 21:04 +0200, Petteri Räty escribió:

> d) something else

e) use a hook around unpack on your local system to detect new build.xml
for a list of packages.

AFAIK, checking changes is part of the bump process, so I think that's a
check you can do either at hand, with a script (it's always a good thing
to look for new files in the project, or look at the diffs), or as I
said in 'e)', use some tricks with /etc/portage/bashrc.

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldwind@gmail.com | GPG: AAD203B5

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Usage of cp -i to prevent overwriting upstream files

[Luca Barbato]

Santiago M. Mola wrote:
  > e) use a hook around unpack on your local system to detect new build.xml
> for a list of packages.
> 
> AFAIK, checking changes is part of the bump process, so I think that's a
> check you can do either at hand, with a script (it's always a good thing
> to look for new files in the project, or look at the diffs), or as I
> said in 'e)', use some tricks with /etc/portage/bashrc.

That looks interesting.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero