Bug 1372923 - Package modified in Fedora exhibits bad behavior when /etc/localtime is old
Summary: Package modified in Fedora exhibits bad behavior when /etc/localtime is old
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-DateTime-TimeZone
Version: 26
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Pisar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-03 20:58 UTC by Don Beusee
Modified: 2017-07-26 17:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-26 07:46:30 UTC
Type: Bug


Attachments (Terms of Use)

Description Don Beusee 2016-09-03 20:58:56 UTC
Description of problem:
I was on FC20 at some point, and upgraded to FC23.  I hadn't noticed until now that my /etc/localtime was a copy and not a symlink of the Los_Angeles zoneinfo file.  So this means my /etc/localtime file is from FC20, even though I'm on FC23.  This causes problems with DateTime::TimeZone package.  I have this test perl program:

#!/usr/bin/perl
use DateTime::TimeZone;
print "DateTime::TimeZone::VERSION=" . $DateTime::TimeZone::VERSION . "\n";
my $ltz = DateTime::TimeZone->new(name => 'local');
print "\n$ltz\n";
print "tz offset=" . $ltz->offset_as_string(-25200) . "\n";

On my system, this program generates the following output:

[root@pp10 ~]# perl test.pl
DateTime::TimeZone::VERSION=2.01

DateTime::TimeZone::Tzfile=HASH(0x1222668)
Can't locate object method "offset_as_string" via package "DateTime::TimeZone::Tzfile" at test.pl line 26.
[root@pp10 ~]#

Note that DateTime::TimeZone->new(name => 'local') returned a DateTime::TimeZone::Tzfile object.  I contacted the maintainer of DateTime::TimeZone, and he assured me this is impossible.  He said this package was modified, and it turns out he's right.  The package from CPAN gives the expected result (proper error message) with the FC20 localtime file.  With a FC23 localtime file, it also works fine (I get Los_Angeles object with offset -0700 reported by the program).  I don't know why this package is modified under the Fedora project.  I debugged, and found the problem to be in the /usr/share/perl5/vendor_perl/DateTime/TimeZone/Local/Unix.pm file.  Unix.pm has code not found in the CPAN version, so it is from the Fedora project.


Version-Release number of selected component (if applicable):
perl-DateTime-TimeZone-2.01-1.fc23.noarch

How reproducible:


Steps to Reproduce:
1. Copy /etc/localtime from an FC20 system to an FC23 system.
2. Run the above test perl program.


Actual results:
DateTime::TimeZone::Tzfile=HASH(0x1222668)
Can't locate object method "offset_as_string" via package "DateTime::TimeZone::Tzfile" at test.pl line 26.

Expected results:
Cannot determine local time zone

Additional info:
The package from CPAN gives the expected result (proper error message) with the FC20 localtime file.  With a FC23 localtime file, it also works fine (I get Los_Angeles object with offset -0700 reported by the program).

Comment 1 Paul Howarth 2016-09-05 07:59:03 UTC
Discussion regarding the downstream patch in Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=1135981
https://rt.cpan.org/Public/Bug/Display.html?id=55029

Comment 2 Petr Pisar 2016-09-05 08:24:10 UTC
Fedora package was modified to use /etc/localtime via DateTime::TimeZone::Tzfile because of bug #1135981.

The issue with DateTime::TimeZone from CPAN is it horribly dies (the "Cannot determine local time zone" error) if time zone name is unknown but /etc/localtime exists which is a valid configuration of a Linux system.

With Fedora's patch, instead of dying, it works in most of the cases. It only cannot retrieve time zone name ("Can't locate object method "offset_as_string"" error) because system time zone files do not provide it.

From this point of view the Fedora's package is less broken than the CPAN's version.

I can look if I can add the offset_as_string() method to DateTime::TimeZone::Tzfile object in this case.

Comment 3 Don Beusee 2016-09-05 11:45:11 UTC
I've read some of the history on this issue, and I don't agree with maintaining your own branch of the package.  Your fix ignores the ill configured system (/etc/localtime out of sync with /usr/share/zoneinfo), which means the system will give incorrect time due to rule changes which /etc/localtime doesn't know about because it's out of date.  I'd rather SOME program tells me something is wrong so I can fix it.  On top of localtime being wrong, tzfile's guess can also be wrong and then you have 2 wrongs.  It's better to raise an error so the sysadmin can fix the system and everything is set right again.  And you don't have to maintain a branch of code trying to ignore a DST patch not properly applied.  I am betting you could talk the package owner into producing a better error message indicating something being wrong with /etc/localtime.

Comment 4 Petr Pisar 2016-09-05 12:23:30 UTC
(In reply to Don Beusee from comment #3)
> Your fix ignores the ill configured system (/etc/localtime out of sync
> with /usr/share/zoneinfo),

This is not ill-configured system. First, glibc reads /etc/locatime, not /usr/share/zoneinfo. Second, DateTime::TimeZone does not use /usr/share/zoneinfo at all. It carries it's own time zone database and that's much bigger problem.

> which means the system will give incorrect time due to rule changes which
> /etc/localtime doesn't know about because it's out of date.

No. System always respects what's in /etc/locatime. It's actually DateTime::TimeZone that ignores it.

>  I'd rather SOME program tells me something is wrong so I can fix it.

From POSIX point of view, there is nothing wrong with the system. From Fedora point of view, you have a local configuration that overrides system time zone definition and such configuration is not a subject of updates.

If something should tell you it's suboptimal, it's not DateTime::TimeZone. Probably a package manager.

I've decided for the patch because it allows systems that exist in the wild to work. Such systems are even used in Fedora build infrastructure. (That's how I hit this issue.)

> On top of localtime being wrong, tzfile's guess can also be wrong and
> then you have 2 wrongs.

I don't know what you mean by "tzfile's guess". DateTime::TimeZone::Tzfile does not guess. It simply does not provide time zone name.

> It's better to raise an error so the sysadmin can fix the system and
> everything is set right again.

Yes.

> And you don't have to maintain a branch of
> code trying to ignore a DST patch not properly applied. I am betting you
> could talk the package owner into producing a better error message
> indicating something being wrong with /etc/localtime.

I don't know what DST patch you talk about. Do you mean tzdata package update? Then you can raise your idea in tzdata bug #107507.

Comment 5 Don Beusee 2016-09-05 14:19:40 UTC
Anytime /etc/localtime is out of date, that represents a broken system from the sysadmin point of view, because s/he applied patches that are not properly applied (despite being installed, it's not being used).  Any package installer updating the zoneinfo files must deal with this problem.  However, that is not the scope of this bug.

As a professional sysadmin and system programmer for 36 years, I submit that patching this Perl package is wrong from both perspectives (sysadmin and programmer).  You cannot unilaterally decide how this package will work, because you're not the owner of it.  The owner has to deal with any/all consequences of his/her decisions on how the package works, because s/he gets the bug reports and support tickets.  You do the sysadmin a disservice by patching a package that is different from the original, behaving differently than if installed from cpan.

You have done me (a fedora user/sysadmin) a disservice because I had to spend many hours debugging an issue that originates with an outdated localtime file compounded by a vendor patch to a package not owned by the vendor.  When the owner told me my error was impossible and must be locally patched, I was in such disbelief that I spent time debugging to see exactly where the issue was, to prove if it was patched or not.  Had I been using the original package from the owner, I would have received a more meaningful error and much sooner got my system fixed of the old localtime file and been on my way.

Just like the owner of glibc can decide to use /etc/localtime, the Perl package owner can decide to use a platform neutral method of maintaining tz data.  It is not for you or I to say it's wrong.  It is wrong however, to modify someone else's code, especially when in disagreement with the owner.  I would not want some vendor modifying my code and I'm sure if you were a package owner, you wouldn't either.

You have agreed with me that it's better to raise an error so the sysadmin is notified there is a problem, but still you disagree with raising an error?  Well, we can disagree, but it's not really your call.  It's the owner's call.

Frankly, I'd lose trust in fedora and redhat if they continue to modify code that's not theirs.  You should be working with package owners to resolve issues and refer users to them when issues arise.  When I find a bug, that's what I do, just as in this case.  I only bugged here because you modified the code in question, and I believe that is, or at the very least, should be, outside your purview.

Providing rpm packages in your distribution should be only a convenience so that we don't have to install a lot of cpan packages.

Comment 6 Emmanuel Seyman 2016-09-05 15:31:04 UTC
(In reply to Don Beusee from comment #5)
> 
> Frankly, I'd lose trust in fedora and redhat if they continue to modify code
> that's not theirs.  You should be working with package owners to resolve

This sounds like a huge disservice to saddle our users with.

If we did not patch the software we package, bugzilla would ask Fedora users
to install perl packages via install-module.pl instead of using dnf/yum, DBD::Sqlite would be using the bundled version of sqlite, different from what the
rest of the distribution is using, resulting in subtle, hard-to-debug bugs. I'm sure there are many other examples.

Comment 7 Don Beusee 2016-09-05 19:30:58 UTC
Bugzilla DOES tell you to install modules using install-module.pl!  LOL!  But if you've ever run check_setup.pl, you'd know that.  Seriously, people use cpan instead of yum/dnf all the time. This is not supposed to be a bad thing!  Sometimes it's the only way to get the latest version people need.  Now I see this is the only way you know what you're getting.

If redhat doesn't want to "saddle it's users", it can work with package owners on their behalf.

Redhat should be contributing to base packages rather than maintaining its own branches.

This is one case where the redhat code is the one "hard-to-debug".

Comment 8 Emmanuel Seyman 2016-09-05 20:54:06 UTC
(In reply to Don Beusee from comment #7)
>
> Bugzilla DOES tell you to install modules using install-module.pl!  LOL! 

Not the one we package. Per user request, we've patched bugzilla to prompt
the user to use dnf instead of install-module.pl.

Comment 9 Don Beusee 2016-09-06 10:30:45 UTC
I figured.  Well, you make it hard for the package owners to support their own s/w on redhat/fedora.  I still say branching the DT::TZ pkg is unnecessary and problematic.  Their code is perfectly fine, and I prefer it.  It would have saved me a lot of time.  BTW, bugzilla is using it incorrectly, which I think you know, since you're monitoring that bugzilla mailing list I emailed.  Since it is your DT::TZ change that breaks bugzilla in this case, you might want to fix your bugzilla.

Comment 10 Fedora End Of Life 2016-11-25 09:33:26 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 11 Fedora End Of Life 2017-07-25 22:49:07 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 12 Don Beusee 2017-07-26 00:19:30 UTC
Petr, how do you plan to deal with the error I originally reported?  I set the version from 24 to 26 so that this isn't auto-closed.

Comment 13 Petr Pisar 2017-07-26 07:46:30 UTC
I plan to keep the behavior you don't like. It's normal Fedora bends upstream code to its needs and this is one of the cases.

Comment 14 Don Beusee 2017-07-26 11:02:07 UTC
So you prefer this:
DateTime::TimeZone::Tzfile=HASH(0x1222668)
Can't locate object method "offset_as_string" via package "DateTime::TimeZone::Tzfile" at test.pl line 26.

Instead of:
Cannot determine local time zone

Even though it's a simple matter to define the routine in Tzfile to return the friendlier error?  Ok then!

Comment 15 Petr Pisar 2017-07-26 15:08:47 UTC
Like "Cannot determine local time zone name"? I could probably. But I thought you are against any divergence from upstream code.

Comment 16 Don Beusee 2017-07-26 17:05:19 UTC
True, but since you're diverging anyway, I'd like to see the error message fixed.


Note You need to log in before you can comment on or make changes to this bug.