[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Getting dh_install to do what we need

Bernd Zeimetz <bernd@bzed.de> writes:

> On 12/07/2011 11:47 PM, Josselin Mouette wrote:
>> Now that weâ??ve made incredible progress in terms of obfuscation, Iâ??d
>> appreciate if we could have a working solution that does not require
>> scripting for the most trivial operations. So what remains? 
>>       * Convincing Joey to revert this useless change and actually
>>         commit something useful. 
>>       * NMU debhelper. 
>>       * Technical committee. 
>>       * Fork dh_install in a new package.
> It is up to you to use debhelper or not, so just use something else -
> you have experience in writing
> tools-which-do-the-same-thing-as-existing-tools. You could report a
> bug report if you don't like it, but it is up to Joey to follow it or
> not. You could do a NMU if you want people to complain about your
> behaviour to DAM. You could even talk to the CTTE if you want to waste
> more people's time.  And yes, you could even fork (its open source!) a
> dh_install package - or instead of wasting ftp master resources, just
> ship your own dh_install script in your debian folders.

I find it kind of funny that just recently Joey complained about Ubuntu
adding a small patch to their debhelper (for DEB_HOST_MULTIARCH support
in .install files) that he claimed would break some packages (although
no examples have been given to substantiate that claim) and he therefore
would ignore the patch and issue completly from then on. To teach Ubuntu
a lesson.

And now he does the same. Even worse because his change DOES break

> I'll happily use the new dh_install feature instead of whining.

You are forgetting that there are more people than just you looking at
your package. By using an obviously verry controversial feature you will
make everybody else life more difficult.

I don't think he is whining. He is trying to find a solution that
everybody can live and work with. And while a package is generally the
Maintainers domain a package also belongs to its users and has to work
together with Debian as a whole. If a major piece of our toolchain for
debian sources suddenly breaks existing sources and pisses of half the
maintainer that is not a good state to have.


Reply to: