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

Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]

One more iteraction.

On 07/01/16 14:31, Mattia Rizzolo wrote:
> On Sun, Jan 03, 2016 at 08:23:34PM +0000, Jose M Calhariz wrote:
>> On 03/01/16 13:21, Mattia Rizzolo wrote:
>>> 43: override_dh_auto_install:
>>> 44:         dh_auto_install
>>> 45:         dh_install
>>> instead please override only dh_install, no need to override
>>> dh_auto_install.
>> Not certain I have done the right thing here.  But I tested and did not
>> change a thing.
> yeah, it doesn't change the outcome, but it's 1) one line less in
> d/rules and 2) more correct.
>>>>> multiarchifying a lib can be hard.  But I don't think this is going to
>>>>> be that hard.  If I were you I'd just try to use dh_auto_configure
>>>>> instead of plain ./configure call, and bump the debhelper compat.
>>>>> See https://wiki.debian.org/Multiarch/Implementation for some hints,
>>>>> note that that page has some outdated bits (but we all hate keeping docs
>>>>> up to date :( )
>>>> Did I get it right?
>>> looks good to me.  though I see there are files like
>>>     ./usr/lib/x86_64-linux-gnu/rep/rules.mk
>>> that might be used by other packages.
>>> but if that one is a makefile, why is it under /usr/lib ?
>>> I need to try a piuparts run, and see if everything is right.
>>> Since there are only two r-deps once this package is more ready I'll try
>>> to build them against this, to see if this multi-lib change affects
>>> them.
>> And I intended to adopt that two r-deps.  What should make it easier.
> Indeed, I'll probably double check this particular bit another day.
> Given that now librep16 is multiarch-able, you should add a
> 'Multi-Arch: same' field in d/control for it.


>>>>>>> * librep-dev.links => no, please.  linking /usr/share/doc/<pkg>
>>>>>>>   directory ain't nice at all, why is that in first place?
>>>> The file  librep-dev.links is gone, but the links are still present. I
>>>> don't know why :-(
>>> those links are caused by the --link-doc option of dh_installdocs.
>>> well, I'm not a fan of --link-doc, I really see too little point in it,
>>> int this case you just save some kB, just gaining troubles.
>>> But give that the current state of librep is a mixed (every binary have
>>> linked docs to librep9, except rep-doc), I'll leave the choice to you.
>>> Your choises are:
>>> * remove --link-doc for rep-doc, then you can just go on
>>> * remove --link-doc altogether, then you need a bunch of .maintscript
>>>   files (see dh_installdeb(1) and dpkg-maintscript-helper(1)
>> I will do this.  But need time to reread the docs.  Moved to TODO file.
> I tried to do this, you can find attached a patch that seems to do this
> transition correctly.


>>>>>>>   + I see there already are preinst snippet to remove the directory.  my
>>>>>>>     reaction to this is: wtf?  it does so quite unconditionally and -.-'
>>>> I changed the maintscripts to something I think is more sane.
>>> I'm not sure what would be the idea behind librep16.preinst ? why do you
>>> remove the symlink of librep9 ?
>>> I haven't tried, but I think that directory goes away when deinstalling
>>> librep9?
> yes it does.  So, can you explain why you did that?

Removed the librep16.preinst

> Something more:
> * d/copyright:
>   + there are 3 spurious line on top, not adhering to DEP-5, also they
>     are redundant.  Please move Mikolaj email address to the debian/*
>     stanza and remove the lines


> + umh, is the Upstream-Name really 'sawfish'?  Isn't it 'rep'?


> * d/control:
>   + vcs-field-not-canonical — please fix it


> * is there a way to fix debian-rules-ignores-make-clean-error ?

I found the problem, Done.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: