Bug 823156 - Reintroduce ddate into Fedora
Summary: Reintroduce ddate into Fedora
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 832819 833254 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-19 14:21 UTC by Jonas Wielicki
Modified: 2018-04-11 09:11 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-24 09:08:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Patch to build ddate into separate package (1.71 KB, patch)
2012-05-19 14:21 UTC, Jonas Wielicki
no flags Details | Diff
Fix wrong license statement (1.70 KB, patch)
2012-05-19 14:27 UTC, Jonas Wielicki
no flags Details | Diff

Description Jonas Wielicki 2012-05-19 14:21:04 UTC
Created attachment 585580 [details]
Patch to build ddate into separate package

Description of problem:
Since util-linux 2.20.1, ddate is not built by default any more. Fedora started this trend and, thus, follows it. 
This creates a backward incompatibility with basically any other major linux distribution out there (most decided to build util-linux with ddate). I created and attached a patch for the util-linux.spec file to build ddate into a separate package, as this seems to be the preferred solution for fedora (according to mailing list[1]).

Version-Release number of selected component (if applicable):
2.20.1 and above

    [1]: <https://lists.fedoraproject.org/pipermail/devel/2011-August/156165.html>

Comment 1 Jonas Wielicki 2012-05-19 14:27:16 UTC
Created attachment 585581 [details]
Fix wrong license statement

ddate is actually Public Domain according to manpage.

Comment 2 Karel Zak 2012-05-21 09:14:51 UTC
If you love ddate so much... what about to fork it from util-linux to a separate ddate upstream package? You can start a new ddate repository somewhere on github, regulary release ddate tarball and add the package to Fedora and another distributiuons.

Comment 3 Jonas Wielicki 2012-05-21 15:15:37 UTC
ddates upstream is beyond the scope of fedora and thus, this bug report. I indeed think that removing ddate from the default configuration was a kind of short-circuit reaction motivated by who-knows-what. The major distributions besides fedora thus decided to build util-linux with ddate[1][2] or at least provide a separate package[3].

I fail to understand why you're so desperate to remove ddate from the linux world (which didn't work out anyway, since most distributions re-included it), especially because, no offense, but, you have made very few rational arguments in all the discussion. Apart from the religious one, it feels for me like the only point from your side was “because I want to”, implicitly brought across via “package it yourself if you want it” or “crazy tool”[4] statements.

As for the religious argument, there has been some discussion on the mailing list, namely the reference to religious texts in the man page of ddate[5]. There was a quote from the Packaging Guidelines:
> Some examples of content which are not permissable:
>
>   Comic book art files
>   Religious texts 
> ...
However, this quote was dragged out of context. In the original source[6], its in a section called “Code vs. Content”. ddate itself, however, is cleary code. Its manpage belongs to ddate as documentation how to use it. If this all is really just about the link in the ddate manpage[7], fedora should reconsider its motto for “content freedom” it states on the main page.

I can also not see how ddate is a burden to maintain. It's not like it was a setuid binary or had a whole bunch of bugs in the last year. How many issues were there with ddate in the whole lifetime of this bugtracker? Run a search, you will (probably) find a whole number of 8 when including closed bugs for a search for “ddate”. One is this one, another is #801659, with a similar request. One is a bug requesting the remove of ddate with the same “rational” arguments as in the mailing list. Two are unrelated bugs where ddate happens to occur in the title/text. Three are actually related: #9601, #666901 and (more or lessly) #637026 (for fun, compare the amount of relevant bugs for fortune. On a first glance, there are at least five). 

So I ask to reintroduce ddate into fedora, be it at util-linux or in a separate package (the first one would actually be preferred). For the sake of completeness within the linux traditions, for the sake of compatibility with other distributions including older fedora versions and to show that fedora is not governed by the arbitary decisions of upstream package maintainers.

        [1]: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650321>
        [2]: <https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/988925>
        [3]: <https://bugs.archlinux.org/task/25826>
        [4]: <https://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=4a8962f3a7cb970b28add7d770528edebbe03635>
        [5]: <https://lists.fedoraproject.org/pipermail/devel/2011-August/156168.html>
        [6]: <https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content>
        [7]: <http://manpages.ubuntu.com/manpages/gutsy/man1/ddate.1.html>

Comment 4 Leon Weber 2012-05-21 15:22:48 UTC
I don't see why it should be necessary to fork ddate when there's already a package that contains it. It would be much cleaner to provide ddate from the util-linux source, either as a default or as a seperate package. Besides, the tool being delivered with linux is nice little reminder for the historic roots of linux/unix that had some healthy nerdy humour, which sadly seems outdated today...

Comment 5 Jonas Wielicki 2012-05-23 14:32:18 UTC
Addendum: From:
<https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/988925/comments/9>
> And I really don't see what harm it does when built by default. It is really 
> not heavy on resources, it is invisible for most users, and very useful to 
> some.
> I totally agree with the Debian folks, and totally disagree with Karel Zak 
> from upstream. It is much crazier to force users to compile util-linux 
> manually, just because they are discordians, than it is to build it by 
> default. Craziness is to assume that somebody is able to do it by just being 
> discordian. And preventing access to such a tool is a violation of some basic 
> human rights.

Comment 6 Karel Zak 2012-05-24 09:08:43 UTC
It seems there is a new ddate(1) upstream:

  https://github.com/bo0ts/ddate

I think you can follow Arch friends and use this new upstream for completely new ddate package. It's also portunity to improve ddate code.

Comment 7 Karel Zak 2012-06-18 09:52:25 UTC
*** Bug 832819 has been marked as a duplicate of this bug. ***

Comment 8 Jonas Wielicki 2012-06-18 16:00:14 UTC
Obviously and as expected, there are more requests for ddate, which is, I think, a reason to repoen this bugreport. Further sources of surprise and rejection of the change to remove ddate:

• <https://lwn.net/Articles/499184/>
• bug 832819

While more people start to disagree, we still did not hear any rational reason for the removal of ddate, while a rational reason _not_ to remove ddate is obviously that it broke regression.

I mean, the main point I have is, that you, Karel Zak, just removed ddate without a giving friggin reason. All I've read is completely irrational and without any logic. I just want to _understand_ what's going on in your mind. What is the reason for you to remove that tool from util-linux? The only “reward” you gain is dislike from the community who uses it and ignorance from those who do not. On the mailing list there were indeed a few people (three, four?) who stood up and said, hey, we ddate do not like ddate. But hell, I do not like KDE either and I know a few others who do not either. Still, KDE is in the Fedora repositories, if I want or not. Okay, you may object that KDE isn't installed by default, but it at least has its own official _spin_ of fedora images.

I'll just quote the guy from lwn who also gave a good point on that:
> It's "pointless junk" like this that makes me believe the Linux world 
> really is different from other places. In the midst of of grey-faced 
> corporate seriousness it's nice to know that you can still find ddate 
> and sometimes even sl. "Was that a train?" -- surprised colleague.

For me it just looks like you made a kneejerk reaction to satisfy a few users and do something you always wanted to do but never had a reason to back you. The few users who agreed with you gave you that “reason”, and now you found that actually, that reason is no reason which can hold against rational discussion, but you're too much of a coward to revert.

Comment 9 Josh Davis 2012-06-18 16:11:51 UTC
Karel Zak, please help me to understand your decision making process.  One user fat-fingered the date command and didn't like the result, so your solution is to break util-linux for users who rely on the ddate command?  Why did you not simply advise this user to take a look at the screen before he hits the enter key and make sure that the command he wishes to run is the command he actually typed?

Please reconsider your decision to not fix the problem that you have introduced.  Thank you.

Comment 10 Karel Zak 2012-06-19 15:19:02 UTC
This is my last reply.

- util-linux upstream is hardly working for years on code and utils
  consolidation and clean up...

- ddate(1) is disabled by default in upstream tree since Aug 2011

- all relevant util-linux upstream contributors and collaborating
  down-stream maintainers (Suse, Arch, Fedora, ...) agree that ddate(1) 
  should be removed from util-linux.

- the decision about Fedora ddate(1) has been publicly discussed at
  fedora-devel list one year ago

- there is new ddate(1) upstream at https://github.com/bo0ts/ddate
  and it seems that the code is maintained by someone who is able to
  follow Discordian's humor/religion

- Fedora is open for new packages, all you need is to follow
  http://fedoraproject.org/wiki/Packaging:Guidelines to create
  ddate.rpm


Personally, I don't want to maintain any code that I don't understand 
and which is completely unnecessary from my point of view. It's my time,
my project, my responsibility and my freedom to make decisions. If you
don't like this nature of the open source world, then install any
commercial Linux distributions and ask for help at paid support.

Fortunately we're talking about open source code, so you can fork the
code (already done at github) and create and maintain the package in Fedora.

Stop trolling, go ahead and invest *your* time to ddate.rpm.

Comment 11 Josh Davis 2012-06-19 16:20:56 UTC
Expressing a legitimate grievance is not trolling.  You are the one who broke util-linux for users who use ddate.

Does this mean that any utility that you don't use personally is potentially on the chopping block?  Is it advisable to rely on the existence of any utility in util-linux?

Comment 12 David Tardon 2012-06-19 17:47:06 UTC
(In reply to comment #11)
> Expressing a legitimate grievance is not trolling.  You are the one who
> broke util-linux for users who use ddate.

You know what? I would not call your behaviour trolling either. I would call it whining. You are trying to force Karel to do something for you that you are not willing to do yourself. The utility is still there, with a new upstream. If you really wanted it so bad, you would just write a new spec and post a RPM for review; I doubt it would take more time that it took you to write the responses here. And since there is evidently (or, better to say, by your evidence) so many people who cannot live without it, it surely would be reviewed in no time.

> 
> Does this mean that any utility that you don't use personally is potentially
> on the chopping block?  Is it advisable to rely on the existence of any
> utility in util-linux?

Now you are trolling. And since I do not like trolls, I can only answer: yes, any utility from util-linux is on the chopping block. The (secret) ultimate plan is to remove everything. So you should go and fork util-linux till there is still time. I wish you luck maintaining your fork!

Comment 13 Josh Davis 2012-06-19 19:12:05 UTC
Point taken.  I apologize to both you and Karel for being snarky.  I'm sorry.

It's not my intention to try and create more work for Karel and force to him create and maintain a new package.  The bug that I filed (832819), which Karel closed as a duplicate of this one, only asked him to revert the change he made to disable this utility.  ddate has been part of util-linux for around fifteen years or so and has never been a problem.  Karel created this issue by disabling this utility with no regard for the people who use it.  If he had just left it alone, then everything would be fine.

I'm reading the packaging guidelines that Karel linked earlier so I can learn how to create packages.  If no one else is already doing this and this is the only way to get this bug fixed, then I'll do it.  It just seems to me that reverting a commit on github would be a much simpler solution.

Comment 14 Jonas Wielicki 2012-06-19 19:22:03 UTC
(In reply to comment #13)
> I'm reading the packaging guidelines that Karel linked earlier so I can
> learn how to create packages.  If no one else is already doing this and this
> is the only way to get this bug fixed, then I'll do it.  It just seems to me
> that reverting a commit on github would be a much simpler solution.

Well, I'm also looking at the fork on github Karel mentioned, and it would not be my first rpm specfile, but the first I'd intend to submit.

The build works fine, I just have to verify it against the packaging guidelines.

Comment 15 Matěj Cepl 2012-06-19 20:54:51 UTC
(In reply to comment #14)
> The build works fine, I just have to verify it against the packaging
> guidelines.

I am not a sponsor (if you need, you have to ask somebody else), but when you have the package ready for submission and when you need a packaging review, let me know. As a Christian I always want to help other religious minorities in the open source, no matter how nonsensical they seem to be ;).

Comment 16 Karel Zak 2012-07-17 12:33:34 UTC
*** Bug 833254 has been marked as a duplicate of this bug. ***

Comment 17 udo.rader 2012-07-24 08:52:14 UTC
Just stumbled into this bug as well, fighting with some our our newly upgraded development boxes that would not run as expected anymore.

ddate has been in util-linux for a very long time, probably much much longer than the person who decided to drop it can call himself a software developer (the oldest version I found dates back to 1994, but thats probably not the oldest version).

Removing core utilities from one of the real core packages in linux without giving at least an installable, ready to use alternative is an annoying thing. And the given explanation says it all:

> I don't want to maintain any code that I don't understand and which is 
> completely unnecessary from my point of view.

And then yelling to the users to build their own version of a package is more than ignorant. 

Open source is exactly not about following a single person's "point of view".

Comment 18 befreeman@vcu.edu 2017-05-15 12:54:40 UTC
Karel Zak,
gobble gobble gobble Gobble Gobble GOBBLE GOBBLE GOBBLE!


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