While a package was being reviewed, the reviewer picked up on a use of the 'dos2unix --keepdate' command:
https://bugzilla.redhat.com/show_bug.cgi?id=478640
The guidelines do indeed say not to use dos2unix, because quote "that can cause build fail on FC3" (like I care).
http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors
But I've used dos2unix before, and it appears that using 'dos2unix --keepdate' is a superior solution because it keeps the original timestamp, and is generally simpler and more obvious to people reading the specfile.
So is this guideline for real?
Rich.
Richard W.M. Jones wrote:
While a package was being reviewed, the reviewer picked up on a use of the 'dos2unix --keepdate' command:
https://bugzilla.redhat.com/show_bug.cgi?id=478640
The guidelines do indeed say not to use dos2unix, because quote "that can cause build fail on FC3" (like I care).
http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors
But I've used dos2unix before,
I use /usr/bin/dos2unix to avoid build breakdowns should dos2unix be moved between packages.
and it appears that using 'dos2unix
--keepdate' is a superior solution because it keeps the original timestamp, and is generally simpler and more obvious to people reading the specfile.
sigh, some people will never understand that keeping timestamps is painting bikesheds :(
So is this guideline for real?
I would label this a "historic wart" of FPG, the FPC should revisit.
Ralf
On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote:
sigh, some people will never understand that keeping timestamps is painting bikesheds :(
Keeping timestamps avoids file conflicts on multilib packages.
On Wed, Jan 14, 2009 at 06:34:16AM -0800, Jesse Keating wrote:
On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote:
sigh, some people will never understand that keeping timestamps is painting bikesheds :(
Keeping timestamps avoids file conflicts on multilib packages.
not really file conflicts, but rpm -V false alarms.
-- Pat
Patrice Dumas wrote:
On Wed, Jan 14, 2009 at 06:34:16AM -0800, Jesse Keating wrote:
On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote:
sigh, some people will never understand that keeping timestamps is painting bikesheds :(
Keeping timestamps avoids file conflicts on multilib packages.
not really file conflicts, but rpm -V false alarms.
in my experience, true conflicts, but only when the multilib'd packages are installed in separate transactions.
-- Rex
On Wed, 2009-01-14 at 09:08 -0600, Rex Dieter wrote:
in my experience, true conflicts, but only when the multilib'd packages are installed in separate transactions.
That got "fixed" a while ago to trigger the conflict no matter what the transaction state is. It was far too confusing to only have conflicts if installing at different times.
Jesse Keating wrote:
On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote:
sigh, some people will never understand that keeping timestamps is painting bikesheds :(
Keeping timestamps avoids file conflicts on multilib packages.
Wrong, ... if they cause conflicts, something else is broken.
It's the contents which matters, not the timestamp.
Ralf
On Wed, 14 Jan 2009, Jesse Keating wrote:
On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote:
sigh, some people will never understand that keeping timestamps is painting bikesheds :(
Keeping timestamps avoids file conflicts on multilib packages.
Nope, timestamps of files are not considered a conflict. Time stamps *in* generated files are what causes conflicts, as the content checksums wont match.
Take for example man- or info-pages: they get compressed at build time so the time stamps will always be different between different builds, no matter what the timestamp of the original file was. If timestamps caused conflicts, no such file could ever be shared even though the content is identical.
The only thing keeping timestamps will help somewhat is avoiding timestamp difference whining on verification with older rpm versions, 4.6.0 filters them out on shared files (as timestamps are not considered a conflict at install time, it's bogus to consider it a verification failure either).
- Panu -
On Wed, Jan 21, 2009 at 04:02:17PM +0200, Panu Matilainen wrote:
Take for example man- or info-pages: they get compressed at build time so the time stamps will always be different between different builds, no matter what the timestamp of the original file was. If timestamps caused conflicts, no such file could ever be shared even though the content is identical.
If I remembmer well, in fedora, man pages timestamps are kept, even if gzipped.
The only thing keeping timestamps will help somewhat is avoiding timestamp difference whining on verification with older rpm versions, 4.6.0 filters them out on shared files (as timestamps are not considered a conflict at install time, it's bogus to consider it a verification failure either).
Ok. then this is not an issue anymore.
-- Pat
On Wed, 21 Jan 2009, Patrice Dumas wrote:
On Wed, Jan 21, 2009 at 04:02:17PM +0200, Panu Matilainen wrote:
Take for example man- or info-pages: they get compressed at build time so the time stamps will always be different between different builds, no matter what the timestamp of the original file was. If timestamps caused conflicts, no such file could ever be shared even though the content is identical.
If I remembmer well, in fedora, man pages timestamps are kept, even if gzipped.
I don't see any attempt to do time stamp preservation in brp-compress (and evidence from packages says the same), would be possible of course if somebody cared enough :) Hmm, would be easy even, as "touch" appears to have the perfect option for it:
-r, --reference=FILE use this file’s times instead of current time
- Panu -
Panu Matilainen wrote, at 01/21/2009 11:22 PM +9:00:
On Wed, 21 Jan 2009, Patrice Dumas wrote:
On Wed, Jan 21, 2009 at 04:02:17PM +0200, Panu Matilainen wrote:
Take for example man- or info-pages: they get compressed at build time so the time stamps will always be different between different builds, no matter what the timestamp of the original file was. If timestamps caused conflicts, no such file could ever be shared even though the content is identical.
If I remembmer well, in fedora, man pages timestamps are kept, even if gzipped.
I don't see any attempt to do time stamp preservation in brp-compress (and evidence from packages says the same), would be possible of course if somebody cared enough :) Hmm, would be easy even, as "touch" appears to have the perfect option for it:
-r, --reference=FILE use this file’s times instead of current time - Panu -
gzip itself keeps timestamps by default (man page also says: By default, gzip keeps the original file name and timestamp in the compressed file)
Mamoru
On Wed, 21 Jan 2009, Mamoru Tasaka wrote:
Panu Matilainen wrote, at 01/21/2009 11:22 PM +9:00:
On Wed, 21 Jan 2009, Patrice Dumas wrote:
On Wed, Jan 21, 2009 at 04:02:17PM +0200, Panu Matilainen wrote:
Take for example man- or info-pages: they get compressed at build time so the time stamps will always be different between different builds, no matter what the timestamp of the original file was. If timestamps caused conflicts, no such file could ever be shared even though the content is identical.
If I remembmer well, in fedora, man pages timestamps are kept, even if gzipped.
I don't see any attempt to do time stamp preservation in brp-compress (and evidence from packages says the same), would be possible of course if somebody cared enough :) Hmm, would be easy even, as "touch" appears to have the perfect option for it:
-r, --reference=FILE use this file’s times instead of current time - Panu -gzip itself keeps timestamps by default (man page also says: By default, gzip keeps the original file name and timestamp in the compressed file)
Ah, so it seems, I had never noticed that.
The differences simply then come from the fact that the files are build-time generated, one way or the other. Just as an example of it, glibc generates it's *.info documentation from *.texi sources, so the timestamps differ regardless of gzip preserving it:
[pmatilai@localhost ~]$ rpm -q --qf "[%{filemtimes} %{filenames}\n]" glibc-devel.x86_64|grep info| head -2 1228741245 /usr/share/info/libc.info-1.gz 1228741245 /usr/share/info/libc.info-10.gz [pmatilai@localhost ~]$ rpm -q --qf "[%{filemtimes} %{filenames}\n]" glibc-devel.i386|grep info| head -2 1228741252 /usr/share/info/libc.info-1.gz 1228741252 /usr/share/info/libc.info-10.gz
- Panu -
On Wed, Jan 21, 2009 at 05:28:02PM +0200, Panu Matilainen wrote:
The differences simply then come from the fact that the files are build-time generated, one way or the other. Just as an example of it, glibc generates it's *.info documentation from *.texi sources, so the timestamps differ regardless of gzip preserving it:
This is quite unusual, in general info pages are pregenerated, to avoid issues with makeinfo version mismatches. Also it is possible, in such cases to use another timestamp (here, for example, the VERSION.texi or similar timestamp) with touch -r to correct timestamps. Some people consider that it is over-engineering, other like to do it.
-- Pat
Patrice Dumas wrote:
On Wed, Jan 21, 2009 at 05:28:02PM +0200, Panu Matilainen wrote:
The differences simply then come from the fact that the files are build-time generated, one way or the other. Just as an example of it, glibc generates it's *.info documentation from *.texi sources, so the timestamps differ regardless of gzip preserving it:
This is quite unusual, in general info pages are pregenerated, to avoid issues with makeinfo version mismatches. Also it is possible, in such cases to use another timestamp (here, for example, the VERSION.texi or similar timestamp) with touch -r to correct timestamps. Some people consider that it is over-engineering, other like to do it.
Please explain, which _bug_ in Fedora's glibc rpm this would fix.
On Wed, Jan 14, 2009 at 09:00:49AM +0000, Richard W.M. Jones wrote:
While a package was being reviewed, the reviewer picked up on a use of the 'dos2unix --keepdate' command:
https://bugzilla.redhat.com/show_bug.cgi?id=478640
The guidelines do indeed say not to use dos2unix, because quote "that can cause build fail on FC3" (like I care).
http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors
But I've used dos2unix before, and it appears that using 'dos2unix --keepdate' is a superior solution because it keeps the original timestamp, and is generally simpler and more obvious to people reading the specfile.
To avoid the dos2unix dependency and still keep timestamp, I use:
sed -e 's/\r//' $file > $file.tmp touch -c -r $file $file.tmp mv $file.tmp $file
But using dos2unix --keepdate with the apropriate BuildRequires (I would use a file BuildRequires) is right too, in my opinion.
By the way I prefer keeping timestamps, in case it wasn't clear.
-- Pat
Richard W.M. Jones wrote:
While a package was being reviewed, the reviewer picked up on a use of the 'dos2unix --keepdate' command:
https://bugzilla.redhat.com/show_bug.cgi?id=478640
The guidelines do indeed say not to use dos2unix, because quote "that can cause build fail on FC3" (like I care).
http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors
This discussion has ranged far afield of the original post.
So, does anyone know of a reason to keep the dos2unix warning? Does it affect EPEL4? If that's the only place we need to worry about, we should mention it but see no reason to definitively say not to use it.
-Toshio
Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a écrit :
This discussion has ranged far afield of the original post.
So, does anyone know of a reason to keep the dos2unix warning?
Is there anything dos2unix does which can not be done by standard tools like sed?
for txt in *.txt ; do iconv -f WINDOWS-1252 -t UTF-8 -o $txt.1 $txt fold -s $txt.1 > $txt.2 sed -i 's/\r//' $txt.2 touch -r $txt $txt.2 mv $txt.2 $txt rm $txt.1 done
Nicolas Mailhot wrote:
Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a écrit :
This discussion has ranged far afield of the original post.
So, does anyone know of a reason to keep the dos2unix warning?
Is there anything dos2unix does which can not be done by standard tools like sed?
for txt in *.txt ; do iconv -f WINDOWS-1252 -t UTF-8 -o $txt.1 $txt fold -s $txt.1 > $txt.2 sed -i 's/\r//' $txt.2 touch -r $txt $txt.2 mv $txt.2 $txt rm $txt.1 done
I don't know of any. But we shouldn't be telling people they must not use dos2unix (with a proper BuildRequires) if there's no actual problem.
-Toshio
On Thu, 2009-01-22 at 02:13 -0800, Toshio Kuratomi wrote:
I don't know of any. But we shouldn't be telling people they must not use dos2unix (with a proper BuildRequires) if there's no actual problem.
dos2unix has a history of not working properly on sparc, but I wouldn't consider that guideline-worthy.
~spot
Toshio Kuratomi wrote:
Nicolas Mailhot wrote:
Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a écrit :
This discussion has ranged far afield of the original post.
So, does anyone know of a reason to keep the dos2unix warning?
Is there anything dos2unix does which can not be done by standard tools like sed?
for txt in *.txt ; do iconv -f WINDOWS-1252 -t UTF-8 -o $txt.1 $txt fold -s $txt.1 > $txt.2 sed -i 's/\r//' $txt.2 touch -r $txt $txt.2 mv $txt.2 $txt rm $txt.1 done
I don't know of any.
The whole point is to replace those 8 confusing lines of scripting with a simple call. It makes the spec file easier to read.
But we shouldn't be telling people they must not use dos2unix (with a proper BuildRequires) if there's no actual problem.
+1
Le Ven 23 janvier 2009 11:39, Denis Leroy a écrit :
Toshio Kuratomi wrote:
Nicolas Mailhot wrote:
Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a écrit :
This discussion has ranged far afield of the original post.
So, does anyone know of a reason to keep the dos2unix warning?
Is there anything dos2unix does which can not be done by standard tools like sed?
for txt in *.txt ; do iconv -f WINDOWS-1252 -t UTF-8 -o $txt.1 $txt fold -s $txt.1 > $txt.2 sed -i 's/\r//' $txt.2 touch -r $txt $txt.2 mv $txt.2 $txt rm $txt.1 done
I don't know of any.
The whole point is to replace those 8 confusing lines of scripting with simple call. It makes the spec file easier to read.
But this simple call does not do half of the stuff of those 8 lines.
It only replaces the sed -i 's/\r//' $txt part
Nicolas Mailhot wrote:
Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a écrit :
This discussion has ranged far afield of the original post.
So, does anyone know of a reason to keep the dos2unix warning?
Is there anything dos2unix does which can not be done by standard tools like sed?
Your consideration defeats the purpose of using tools. It's their purpose to avoid such scripts.
Ralf
packaging@lists.fedoraproject.org
-
Denis Leroy -
Jason L Tibbitts III -
Jesse Keating -
Mamoru Tasaka -
Nicolas Mailhot -
Panu Matilainen -
Patrice Dumas -
Ralf Corsepius -
Rex Dieter -
Richard W.M. Jones -
Tom Callaway -
Toshio Kuratomi