Re: Bug#834013: emboss, emboss-data: both packages ship /usr/share/man/man1/em_cons.1e.gz

2016-08-12 Thread James Cowgill 
Hi,

On 12/08/16 14:58, Andreas Tille wrote:
> Hi,
> 
> this version was a source only upload.  If I build on my local machine
> emboss-data does not contain any dir /usr/share/man.  However, the
> binary package on the Debian mirror contains /usr/share/man/man1 with
> has two symlinks which are identical to those in the emboss package.
> 
> I can not reproduce this and I'm wondering why the source only upload
> creates files that are not created on a local build.

debian/rules contains:

override_dh_installman:
dh_installman -a -p emboss
for i in $(RENAMED) ; \
do dh_link usr/share/man/man1/$$i.1e.gz
usr/share/man/man1/em_$$i.1e.gz ; \
done

dh_link will install the symlink into the first package in debhelper's
list of packages. When doing an arch:amd64 upload this is "emboss", but
when doing an arch:all upload (which happens when you do a source
uploaded) this is "emboss-data". Thus you get two symlinks which
conflict with each other.

You should be able to reproduce this by doing two separate builds:
 One with dpkg-buildpackage -B
 One with dpkg-buildpackage -A

And comparing the generated debs.

The simple solution is to use "dh_link -pemboss" to force the symlinks
to be installed into that package.

James



signature.asc
Description: OpenPGP digital signature

Re: Bug#834013: emboss, emboss-data: both packages ship /usr/share/man/man1/em_cons.1e.gz

2016-08-12 Thread Gianfranco Costamagna 
Hi,



>this version was a source only upload.  If I build on my local machine
>emboss-data does not contain any dir /usr/share/man.  However, the
>binary package on the Debian mirror contains /usr/share/man/man1 with
>has two symlinks which are identical to those in the emboss package.


seems you didn't split the dh_link into an arch-indep and an arch-dep
target, and you do the same link regardless of which package they will go 
inside.

so, the links for the arch-indep seems to be created when building the arch-dep
packages.

>I can not reproduce this and I'm wondering why the source only upload
>creates files that are not created on a local build.


probably your local build is broken and builds only arch-dep packages?
I can't say without a build log.


(note: I didn't really debug this issue, the rules file seems overly 
complicated to me)

G.

Re: Bug#834013: emboss, emboss-data: both packages ship /usr/share/man/man1/em_cons.1e.gz

2016-08-12 Thread Andreas Tille 
Hi,

this version was a source only upload.  If I build on my local machine
emboss-data does not contain any dir /usr/share/man.  However, the
binary package on the Debian mirror contains /usr/share/man/man1 with
has two symlinks which are identical to those in the emboss package.

I can not reproduce this and I'm wondering why the source only upload
creates files that are not created on a local build.

Kind regards

   Andreas.

On Thu, Aug 11, 2016 at 02:18:00PM +0200, Andreas Beckmann wrote:
> Package: emboss,emboss-data
> Version: 6.6.0+dfsg-4
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> 
> Hi,
> 
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
> 
>   Selecting previously unselected package emboss.
>   (Reading database ... 
> (Reading database ... 8365 files and directories currently installed.)
>   Preparing to unpack .../emboss_6.6.0+dfsg-4_amd64.deb ...
>   Unpacking emboss (6.6.0+dfsg-4) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/emboss_6.6.0+dfsg-4_amd64.deb (--unpack):
>trying to overwrite '/usr/share/man/man1/em_cons.1e.gz', which is also in 
> package emboss-data 6.6.0+dfsg-4
>   Errors were encountered while processing:
>/var/cache/apt/archives/emboss_6.6.0+dfsg-4_amd64.deb
> 
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
> 
> 
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
> 
> Cheers,
> 
> Andreas
> 
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html


> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de