Bryan>>> I think Hwclock should be distributed through a project of its own and
Bryan>>> repackaged directly into Linux distributions like thousands of other
Bryan>>> packages including util-linux(-ng).
Karel> I don't so ;-)
Karel>
Karel> The util-linux-ng project is open for arbitrary sane patches --
Karel> everyone is welcome, including Bryan. I don't think that I have a
Karel> problem to collaborate with other people. We already have a community
Karel> around util-linux-ng (including RTC kernel developers). We are ready
Karel> to maintain and improve hwclock(8), do you want to help us?
Karel>
Karel> Why do you need to maintain your hwclock separately? I don't see a real
Karel> technical reason.
The historic reason is that an old version of hwclock was captured into
util-linux long ago, and not maintained in parallel with the separate
hwclock project that _already existed_ at that time.
Bryan has done a huge amount of work on hwclock since then. Not
speaking for him, but I am sure he would not be willing to submerge the
separate hwclock project into util-linux(-ng) unless it picked up all
the changes since the fork.
Are you prepared to do that?
Bela>> 4) modify util-linux-ng packaging to _by default_ omit hwclock, while
Karel> Why? Where is a group of people who need the change? The freedom of
Karel> choice between util-linux and Bryan's hwclock(8) exists for more than
Karel> 7 years. The reality is that all mainstream Linux distributions
Karel> *successfully* use util-linux(-ng) hwclock.
It's true. It's also true that the util-linux hwclock is old, has lots
of old bugs and weaknesses, and some mainline distro users suffer for
those.
There's no need to split off the packaging _if_ util-linux picks up a
current hwclock, so I guess it's all up to you. That's sort of
irrespective of whether Bryan moves his development focus inside
util-linux-ng. If the two were resynch'd to the present and maintained
more or less in parallel thenceforth, it's not important which is the
"master" tree.
It's silly that this should come down to a sort of a turf war. I don't
even think the people who did the original fork are still associated
with util-linux. Why defend someone else's bogus decisions of the
ancient past?
Karel> BTW, I see a completely different trend in Linux distributions --
Karel> consolidation -- bigger, community driven and well maintained groups
Karel> of packages/utils rather than small one-man projects.
Karel>
Karel> IMHO --disable-hwclock makes more sense for the minority of Linux
Karel> users who don't want (or cannot -- e.g. s390) use hwclock(8).
Seems like the build should know at build time whether it's a workable
architecture. If not, perhaps hwclock binary should be emitted which
simply prints advisory error messages ("hwclock is not supported on this
architecture (s390)") and exits _without_ an error code. Actually it
could still do stuff like printing current time, making it compatible
with scripts that might parse the output. Or whatever. Not very
important.
Karel> Again, your patches are welcomed.
Are you really going to welcome a set of patches the brings
util-linux-ng hwclock up to parity with Bryan's (plus any useful bits
that may exist in the util-linux(-ng) branch)?
>Bela<
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
