FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-16-2009, 10:11 AM
Goswin von Brederlow
 
Default Mass bugfiling in preparation for multiarch

Hi,

over the weekend I did some work on multiarch again and did notice
some new and old problems when adding more libraries to my test set.

Given that the problems are quite easily detectable I'm considering
scanning all packages for their occurance and reporting bugs for them.
In detail I'm looking for the following situations violating 'Policy
8.2 Shared library support files':

1) Library packages that contain public binary ([/usr]/[s]bin/*)

Policy 8.2 says:

| If your package contains files whose names do not change with each
| change in the library shared object version, you must not put them in
| the shared library package. Otherwise, several versions of the shared
| library cannot be installed at the same time without filename clashes,
| making upgrades and transitions unnecessarily difficult.

Example: libc6 contains /usr/sbin/zic, /usr/bin/getent and several more

libc6 must be split into libc-bin and libc6 packages.


2) Library packages that contain conffiles

First Policy 8.2. If the conffiles are not named in a way that changes
with each soname change then this is a violation of a MUST directive.

Example: libc6 conatins /etc/gai.conf


Secondly even conffiles with unique names will be a problem for
multiarch. The library package would be installed from i386
and amd64 resulting in 2 debs with the same conffile.

Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf

For this I want to file bugs (on top of violations of the MUST
directive) requesting that either the conffile is split into a
seperate package (say you already have a libfoo and foo-bin package)
or made unique for the target:
/etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf.


3) Library packages that contain shared files

Policy 8.2 goes on to say this about shared files:

| If the program or file is architecture independent, the
| recommendation is for it to be placed in a subdirectory of
| /usr/share instead, preferably under
| /usr/share/package-name. Following the package-name naming
| convention ensures that the file names change when the shared object
| version changes.

But the MUST directive of 8.2 still remains and packages not using a
/usr/share/package-name but something more generic are in violation.

Example: libasound2 contains /usr/share/alsa/alsa.conf
libarts1c2a conatins /usr/share/man/man1/artsdsp.1.gz


Again for multiarch this becomes more complicated.
/usr/share/package-name will still cause a conflict between the i386
and amd64 flavour of a library package. For this I want to file bugs
(again on top of the violations of the MUST directive) requesting that
either the shared data is split out into libfoo-common packages or, in
case of verry small files, moved out of shared into the multiarch
library path: /usr/lib/x86_64-linux-gnu/package/.

Example: libdirectfb-1.0-0 contains /usr/share/directfb-1.0.1/cursor.dat



Any objections to this? Note that most will be violations of a MUST
directive of policy.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-16-2009, 11:15 AM
Josselin Mouette
 
Default Mass bugfiling in preparation for multiarch

Le lundi 16 mars 2009 12:11 +0100, Goswin von Brederlow a crit :
> Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf
>
> For this I want to file bugs (on top of violations of the MUST
> directive) requesting that either the conffile is split into a
> seperate package (say you already have a libfoo and foo-bin package)
> or made unique for the target:
> /etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf.

Insane. This file must, of course, be moved to libgtk2.0-common instead.

--
.'`. Debian 5.0 "Lenny" has been released!
: :' :
`. `' Last night, Darth Vader came down from planet Vulcan and told
`- me that if you don't install Lenny, he'd melt your brain.
 
Old 03-16-2009, 01:55 PM
Goswin von Brederlow
 
Default Mass bugfiling in preparation for multiarch

Josselin Mouette <joss@debian.org> writes:

> Le lundi 16 mars 2009 12:11 +0100, Goswin von Brederlow a crit :
>> Example: libgtk2.0-0 contains /etc/gtk-2.0/im-multipress.conf
>>
>> For this I want to file bugs (on top of violations of the MUST
>> directive) requesting that either the conffile is split into a
>> seperate package (say you already have a libfoo and foo-bin package)
>> or made unique for the target:
>> /etc/gtk-2.0-x86_64-linux-gnu/im-multipress.conf.
>
> Insane. This file must, of course, be moved to libgtk2.0-common instead.

That depends on the contents of the file. In this example the file is
architecture independent so duplicating it per target is stupid.

In other cases there would be a list of available plugins for an
application. And for every target triplet the list of plugins can
differ. In those cases adding the triplet to either the dir or the
filename makes sense.

E.g. /etc/libfoo/plugins-x86_64-linux-gnu.d/

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-16-2009, 08:25 PM
Aurelien Jarno
 
Default Mass bugfiling in preparation for multiarch

On Mon, Mar 16, 2009 at 12:11:35PM +0100, Goswin von Brederlow wrote:
> Hi,
>
> over the weekend I did some work on multiarch again and did notice
> some new and old problems when adding more libraries to my test set.
>
> Given that the problems are quite easily detectable I'm considering
> scanning all packages for their occurance and reporting bugs for them.
> In detail I'm looking for the following situations violating 'Policy
> 8.2 Shared library support files':
>

[snip]

> Any objections to this? Note that most will be violations of a MUST
> directive of policy.
>

If you want to get some more multiarch ennemies, this is clearly the
way to go.

The alternate method is to post a list to debian-devel, and when we have
a basic multiarch support, you may start thinking about filling bugs.
Not before.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-16-2009, 09:40 PM
Russ Allbery
 
Default Mass bugfiling in preparation for multiarch

Aurelien Jarno <aurelien@aurel32.net> writes:

> If you want to get some more multiarch ennemies, this is clearly the way
> to go.
>
> The alternate method is to post a list to debian-devel, and when we have
> a basic multiarch support, you may start thinking about filling bugs.
> Not before.

Well, regardless of the benefits for multiarch, library packages
containing binaries that don't change names with different SONAMEs violate
a Policy must at present. So either they're RC bugs or Policy is wrong
about the severity.

It's a theoretical problem in libc6 in particular since the chances of
libc6 changing SONAMEs again is low and there would be a lot of other work
to have to do to deal with that apart from the binaries in /usr/bin, but
the situation for other libraries is much more concrete. I've already
filed an RC bug about this in one other package that I ran into. I think
such bugs are fair game regardless of whether or not we're trying to
implement multiarch (with the normal caveats about mass bug filing).

If the file does change with SONAME, that's a different matter, and that
part depends more on our multiarch direction.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-16-2009, 10:19 PM
Aurelien Jarno
 
Default Mass bugfiling in preparation for multiarch

On Mon, Mar 16, 2009 at 03:40:53PM -0700, Russ Allbery wrote:
> Aurelien Jarno <aurelien@aurel32.net> writes:
>
> > If you want to get some more multiarch ennemies, this is clearly the way
> > to go.
> >
> > The alternate method is to post a list to debian-devel, and when we have
> > a basic multiarch support, you may start thinking about filling bugs.
> > Not before.
>
> Well, regardless of the benefits for multiarch, library packages
> containing binaries that don't change names with different SONAMEs violate
> a Policy must at present. So either they're RC bugs or Policy is wrong
> about the severity.
>
> It's a theoretical problem in libc6 in particular since the chances of
> libc6 changing SONAMEs again is low and there would be a lot of other work
> to have to do to deal with that apart from the binaries in /usr/bin, but
> the situation for other libraries is much more concrete. I've already
> filed an RC bug about this in one other package that I ran into. I think
> such bugs are fair game regardless of whether or not we're trying to
> implement multiarch (with the normal caveats about mass bug filing).
>
> If the file does change with SONAME, that's a different matter, and that
> part depends more on our multiarch direction.
>

Still mass filling bugs is not the solution here. As it see seems we like
policy and reference, let me quote the developer reference 7.2:

"Please use the programms dd-list and if appropriate whodepends (from
the package devscripts) to generate a list of all affected packages, and
include the output in your mail to <debian-devel@lists.debian.org>."

That's what I suggested.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-17-2009, 09:34 AM
Goswin von Brederlow
 
Default Mass bugfiling in preparation for multiarch

Aurelien Jarno <aurelien@aurel32.net> writes:

> On Mon, Mar 16, 2009 at 12:11:35PM +0100, Goswin von Brederlow wrote:
>> Hi,
>>
>> over the weekend I did some work on multiarch again and did notice
>> some new and old problems when adding more libraries to my test set.
>>
>> Given that the problems are quite easily detectable I'm considering
>> scanning all packages for their occurance and reporting bugs for them.
>> In detail I'm looking for the following situations violating 'Policy
>> 8.2 Shared library support files':
>>
>
> [snip]
>
>> Any objections to this? Note that most will be violations of a MUST
>> directive of policy.
>>
>
> If you want to get some more multiarch ennemies, this is clearly the
> way to go.
>
> The alternate method is to post a list to debian-devel, and when we have
> a basic multiarch support, you may start thinking about filling bugs.
> Not before.

So we should just ignore blatant policy violation until the moment they
do bite us in the ass? So we wait until the verry last moment when
everything would be ready to use multiarch and then we freeze squeeze
before package can be fixed to be multiarch compatible?

And by the way. We had basic multiarch support before sarge. This is
not "before". This is after it has already killed multiarch for 2
stable releases. If we don't get things moving in parallel it will
never be ready for squeeze either.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-17-2009, 09:38 AM
Aurelien Jarno
 
Default Mass bugfiling in preparation for multiarch

Goswin von Brederlow a crit :
> Aurelien Jarno <aurelien@aurel32.net> writes:
>
>> On Mon, Mar 16, 2009 at 12:11:35PM +0100, Goswin von Brederlow wrote:
>>> Hi,
>>>
>>> over the weekend I did some work on multiarch again and did notice
>>> some new and old problems when adding more libraries to my test set.
>>>
>>> Given that the problems are quite easily detectable I'm considering
>>> scanning all packages for their occurance and reporting bugs for them.
>>> In detail I'm looking for the following situations violating 'Policy
>>> 8.2 Shared library support files':
>>>
>> [snip]
>>
>>> Any objections to this? Note that most will be violations of a MUST
>>> directive of policy.
>>>
>> If you want to get some more multiarch ennemies, this is clearly the
>> way to go.
>>
>> The alternate method is to post a list to debian-devel, and when we have
>> a basic multiarch support, you may start thinking about filling bugs.
>> Not before.
>
> So we should just ignore blatant policy violation until the moment they
> do bite us in the ass? So we wait until the verry last moment when
> everything would be ready to use multiarch and then we freeze squeeze
> before package can be fixed to be multiarch compatible?

No, the first step is to provide a list of affected package, just as
explained in the developer reference. You should also discuss with
ftpmaster, as such changes has been rejected by them, for example libc6
split into libc-bin.

> And by the way. We had basic multiarch support before sarge. This is
> not "before". This is after it has already killed multiarch for 2
> stable releases. If we don't get things moving in parallel it will
> never be ready for squeeze either.

Yeah, we clearly don't have multiarch support because of libraries
installing files in the wrong place. Not because we don't have
toolchain/dpkg support.

--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-17-2009, 09:41 AM
Michal Čihař
 
Default Mass bugfiling in preparation for multiarch

Hi

Dne Tue, 17 Mar 2009 11:34:28 +0100
Goswin von Brederlow <goswin-v-b@web.de> napsal(a):

> So we should just ignore blatant policy violation until the moment they
> do bite us in the ass? So we wait until the verry last moment when
> everything would be ready to use multiarch and then we freeze squeeze
> before package can be fixed to be multiarch compatible?
>
> And by the way. We had basic multiarch support before sarge. This is
> not "before". This is after it has already killed multiarch for 2
> stable releases. If we don't get things moving in parallel it will
> never be ready for squeeze either.

How about first providing list of affected packages (processed through
dd-list)? I'm pretty sure that many issues will be fixed just after you
point them out, just the maintainer was not aware of this problem.

PS: This also looks to me like good candidate for lintian test, have
you considered also this option?

--
Michal Čihař | http://cihar.com | http://blog.cihar.com
 
Old 03-17-2009, 09:48 AM
Goswin von Brederlow
 
Default Mass bugfiling in preparation for multiarch

Aurelien Jarno <aurelien@aurel32.net> writes:

> On Mon, Mar 16, 2009 at 03:40:53PM -0700, Russ Allbery wrote:
>> Aurelien Jarno <aurelien@aurel32.net> writes:
>>
>> > If you want to get some more multiarch ennemies, this is clearly the way
>> > to go.
>> >
>> > The alternate method is to post a list to debian-devel, and when we have
>> > a basic multiarch support, you may start thinking about filling bugs.
>> > Not before.
>>
>> Well, regardless of the benefits for multiarch, library packages
>> containing binaries that don't change names with different SONAMEs violate
>> a Policy must at present. So either they're RC bugs or Policy is wrong
>> about the severity.
>>
>> It's a theoretical problem in libc6 in particular since the chances of
>> libc6 changing SONAMEs again is low and there would be a lot of other work
>> to have to do to deal with that apart from the binaries in /usr/bin, but
>> the situation for other libraries is much more concrete. I've already
>> filed an RC bug about this in one other package that I ran into. I think
>> such bugs are fair game regardless of whether or not we're trying to
>> implement multiarch (with the normal caveats about mass bug filing).
>>
>> If the file does change with SONAME, that's a different matter, and that
>> part depends more on our multiarch direction.

I will try to look for both cases but split the list into those that
violate the MUST and those that are only a problem for multiarch. I'm
not expecting so many of the later. Use of the SONAME looked rare in
the small set I worked with so far.

> Still mass filling bugs is not the solution here. As it see seems we like
> policy and reference, let me quote the developer reference 7.2:
>
> "Please use the programms dd-list and if appropriate whodepends (from
> the package devscripts) to generate a list of all affected packages, and
> include the output in your mail to <debian-devel@lists.debian.org>."
>
> That's what I suggested.

Except you didn't say that. What you first wrote I read as "Don't you
dare file any bugs for any of them."

Reading this mail it seems you more probably ment "Lets generate a
list first and then talk about it again.".

Sorry for my strong first reply.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 09:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org