:: Re: [DNG] new dbus packages for ASC…
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Didier Kryn
日付:  
To: dng
題目: Re: [DNG] new dbus packages for ASCII in experimental -- PLEASE HELP TESTING
Le 15/06/2017 à 17:52, Steve Litt a écrit :
> On Thu, 15 Jun 2017 12:39:32 +0100
> KatolaZ <katolaz@???> wrote:
>
>> On Thu, Jun 15, 2017 at 01:27:19PM +0200, Antony Stone wrote:
>>> No chance of getting things like this reduced from "depends" to
>>> "recommends", I suppose?
>>>
>> I asked the maintainer if he could do that, and he gently explained me
>> that a bug in gconf didn't allow anything less than a Depends: (so a
>> lesstif package has a Depends: on gconf because a GNOME-related goodie
>> added by the Debian maintainer requires gconf, and gconf has a bug
>> which does not allow to use the GNOME-related additional goodie if it
>> is not already installed when the lesstif app gets installed. And we
>> still think that this is not *TOTALLY* *SICK* o_O).
>> He kindly promised he would have looked into that after stretch is
>> out. The dependency was introduced in 2007.
> Very good point. The Debian project was already drifting toward
> disfunctionality back in 2007, when systemd was just a gleam in
> poetterpuff's eye. As the originator and then-sub-maintainer of the
> VimOutliner project, I had to help people with broken Debian package
> manager installed VimOutliner software by having them uninstall and
> then Linux-install our (upstream) software. The debianistas went so far
> as to substitute the wrist-twisting, repetative motion inducing,
> keyboard dependent "\\" for VimOutliner's trivial and lightning fast
> ",," mode-change key. Because some Debian policy toward Vim demanded it.
>
>> The alternative solution would be to fork the package for Devuan, and
>> add it to the pile.
> The preceding alterative would certainly be ideal, if the manpower
> existed. Absent such massive manpower, would it be possible to provide
> fakeout packages gnome-whatever-faux, gnome-whatever2-faux, etc, which
> would allow Gnome-infested programs to compile, but do nothing other
> than write message "gnome-whatever-faux fcn whichever() called" to
> stderr for debugging purposes?
>
>> All this madness would have been unnecessary if
>> the entanglement with GNOME had not been seen as a necessity by a lot
>> of Debian maintainers.
> What people need to be reminded of, over and over again, is that
> dependencies aren't cheap. Upstreams, packagers and users need to be
> continuously reminded not to insert dependencies unless the majority of
> the dependent software is used and necessary, and continuously reminded
> to prune existing dependencies, writing their own code to substitute
> for minor features bestowed by gargantuan libraries. Each dependency
> bestows the opportunity of compile failure, of packaging workarounds,
> and of installing software the user/admin considers toxic. Much the
> same as a shopper carefully weighs the price and value of an item
> before buying, the upstream or packager must frugally screen each
> temptation to include a dependency, "buying" only those dependencies
> critical to the software's basic functionality, and too difficult to
> custom-write in a timely manner.
>
> Here's a heresy you can quote me on: Perhaps if a feature is too
> difficult to code without depending on a big library, that feature
> should not be built! Five or ten users calling for an obscure feature
> doesn't provide an excuse for a major library inclusion.
>
> People puff out their chests in wisdom as they mouth the words "don't
> reinvent the wheel", but all too often these efficiency gurus can be
> seen importing a whole wheel when all they need is one spoke nipple. A
> repudiation of the universal call of "don't reinvent the wheel" needs
> to be made, with the appropriate re-education.
>
> SteveT


     Note that, with free software, it is possible to avoid dependency 
without reinventing the wheel: just "steal" the source, if the big 
library is not too entangled. If the wheel needs to be reinvented it 
means the library was not written with freedom in mind.


     Didier