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

Bug#706043: re-name: really necessary?



Hi Jonathan and Jakub,

Thanks a lot for your reply.

Thus I' ve a doubt now. Should I keep the original name in tarball
(rename) and in the binary (renamex)?

I don't known about versioning scheme changes. Thanks.

The regex.h is used! The regex.c no. But I think I needn't change the
upstream tarball content.

I used this program in the last year and it has new features. Then I
thought to put in Debian to help the users. I already explained about
it in a past message. However, because the general dissatisfaction I
will drop this package.

Thanks for help.

Regards,

Eriberto



2013/4/24 Jakub Wilk <jwilk@debian.org>:
> * Jonathan Dowland <jmtd@debian.org>, 2013-04-24, 11:21:
>
>> I'm also not clear on why you've renamed the upstream name from rename to
>> re-name. You claim in README.Source:
>>
>>> It is a generical name and was modified to re-name to be introduced in
>>> Debian.
>>
>>
>> "rename" is not a current package name, re-name is just as generic with
>> the added disadvantage that it is not the upstream name.
>
>
> I am more concerned that name of the binary ("renamex") was also changed.
>
>
>> Although I suppose alternatives would not be appropriate for
>> /usr/bin/rename, since the calling syntax is completely different to prename
>
>
> Indeed.
>
>
>> (not sure which other packages provide a /usr/bin/rename alternative),
>
>
> There are no such packages. The alternative is just an artifact from the
> past. See bugs #304705, #439935.
>
>
>> As an irrelevant side-note it's nice to see a debian/rules file that adds
>> --parallel to dh(1) calls.
>
>
> Yeah, it saves like 0.1s of build time. ;)
>
> Why is your .orig.tar different than the one uscan downloads?
>
> You build-depend on "debhelper (>= 9.0.0)" but debhelper no longer uses such
> versioning scheme. Use just "debhelper (>= 9)".
>
> Typo in README.en.txt and in the package description:
> substitue -> substitute.
>
> Please honour DEB_BUILD_OPTIONS=noopt.
>
> blhc emits:
> CFLAGS missing (-g -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security): gcc -Wall -O3  -DHAVE_CONFIG_H -DCFG_UNIX_API
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro -c -o main.o main.c
> CFLAGS missing (-g -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security): gcc -Wall -O3  -DHAVE_CONFIG_H -DCFG_UNIX_API
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro -c -o rename.o rename.c
> CFLAGS missing (-g -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security): gcc -Wall -O3  -DHAVE_CONFIG_H -DCFG_UNIX_API
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro -c -o fixtoken.o fixtoken.c
>
> Lintian 2.5.12 emits:
> X: re-name: binary-file-built-without-LFS-support usr/bin/re-name
>
> If it was a bit smarter, it would also emit hyphen-used-as-minus-sign.
>
> config.h reads "Generated automatically by configure." So where is this
> configure?
>
> Do you know what are regex.c and regex.h for? They constitute >50% of the
> tarball size, yet they don't appear to be used at all.
>
> --
> Jakub Wilk


Reply to: