[devel] noarch and /usr/share (packages/aptitude: tags/0.4.5-alt5)

[devel] noarch and /usr/share (packages/aptitude: tags/0.4.5-alt5)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

On Mon, Dec 21, 2009 at 06:40:28PM +0300, Alexey I. Froloff wrote:
>     0.4.5-alt5
>     
>     - Packaged User's Manual, dropped useless data and developer README's
>     - doc subpackage made noarch
>     - Resurrected changelog viewer

> --- a/aptitude.spec
> +++ b/aptitude.spec
> @@ -2,7 +2,7 @@
>  
>  Name: aptitude
>  Version: 0.4.5
> -Release: alt4
> +Release: alt5
>  
>  Summary: Terminal-based apt frontend
>  Group: System/Configuration/Packaging
> @@ -29,6 +29,15 @@ can't be ported to apt-rpm.
>  %package doc
>  Summary: English manual for aptitude, a terminal-based apt frontend
>  Group: Books/Computer books
> +# Can't use noarch:
> +#--- aptitude-doc-0.4.5-alt5.noarch.rpm.i586     2009-12-21 18:23:35 +0300
> +#+++ aptitude-doc-0.4.5-alt5.noarch.rpm.x86_64   2009-12-21 18:23:35 +0300
> +#@@ -77,35 +77,35 @@
> +# /usr/share/doc/aptitude-doc-0.4.5/index.html
> +#-/usr/share/doc/aptitude-doc-0.4.5/ld-id2608397.html
> +#+/usr/share/doc/aptitude-doc-0.4.5/ld-id3016206.html
> +#...
> +#BuildArch: noarch
>  Conflicts: %name < %version-%release
>  Conflicts: %name > %version-%release

Shouldn't /usr/share part of the packages be identical, much the same
way as noarch packages must be identical?

I think I am going to implement much stricter checking for both noarch
packages and /usr/share part of arch packages.  Also, I am going to
implement new "force-noarch" check which will require some packages
be noarch (by the principle of "extensional equality").

If you don't like it, now is the right time to have your say.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] noarch and /usr/share (packages/aptitude: tags/0.4.5-alt5)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3999 bytes --]

On Tue, Dec 22, 2009 at 02:36:16AM +0300, Alexey Tourbin wrote:
> > @@ -29,6 +29,15 @@ can't be ported to apt-rpm.
> >  %package doc
> >  Summary: English manual for aptitude, a terminal-based apt frontend
> >  Group: Books/Computer books
> > +# Can't use noarch:
> > +#--- aptitude-doc-0.4.5-alt5.noarch.rpm.i586     2009-12-21 18:23:35 +0300
> > +#+++ aptitude-doc-0.4.5-alt5.noarch.rpm.x86_64   2009-12-21 18:23:35 +0300
> > +#@@ -77,35 +77,35 @@
> > +# /usr/share/doc/aptitude-doc-0.4.5/index.html
> > +#-/usr/share/doc/aptitude-doc-0.4.5/ld-id2608397.html
> > +#+/usr/share/doc/aptitude-doc-0.4.5/ld-id3016206.html
> > +#...
> > +#BuildArch: noarch
> >  Conflicts: %name < %version-%release
> >  Conflicts: %name > %version-%release
> 
> Shouldn't /usr/share part of the packages be identical, much the same
> way as noarch packages must be identical?
> 
> I think I am going to implement much stricter checking for both noarch
> packages and /usr/share part of arch packages.  Also, I am going to
> implement new "force-noarch" check which will require some packages
> be noarch (by the principle of "extensional equality").

http://git.altlinux.org/people/at/packages/girar-builder.git
642af655  gb-task-check-noarch-i: force noarch by extensional equality
9bce38b3  gb-task-check-noarch-i: check for identical /usr/share part in arch pacakges
60af4a7c  gb-task-check-noarch-i: use rpmfile(1) to check noarch cpio contents
67f83c43  gb-task-check-noarch-i: use ls again
17d6d4ea  gb-task-check-noarch, gb-task-check-noarch-i: factored from gb-task-check-build-i

Examples.

1) Cannot package static binary into noarch package.
E.g. cannot make cpio-static noarch.

[at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 1
--- cpio-static-2.10-alt4.noarch.rpm.i586       2009-12-22 10:54:20 +0300
+++ cpio-static-2.10-alt4.noarch.rpm.x86_64     2009-12-22 10:54:20 +0300
@@ -1,2 +1,2 @@
-/usr/bin/cpio.static   100755  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, stripped
+/usr/bin/cpio.static   100755  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, stripped
 Requires: cpio = 2.10-alt4
error (#1): non-identical noarch packages
[at@people 17774]$ 


2) Arch packages must have identical /usr/share parts.
E.g. cannot use %doc to package binary files.

[at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 4
--- python-module-pyorbit-2.24.0-alt1.2.i586.rpm.usr-share      2009-12-22 10:55:33 +0300
+++ python-module-pyorbit-2.24.0-alt1.2.x86_64.rpm.usr-share    2009-12-22 10:55:33 +0300
@@ -15,11 +15,11 @@
 /usr/share/doc/python-module-pyorbit-2.24.0/tests/c-inproc/.libs/TestCall_module.lai   100644  libtool library file
-/usr/share/doc/python-module-pyorbit-2.24.0/tests/c-inproc/.libs/TestCall_module.so    100755  ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
-/usr/share/doc/python-module-pyorbit-2.24.0/tests/c-inproc/.libs/c-impl.o      100644  ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
+/usr/share/doc/python-module-pyorbit-2.24.0/tests/c-inproc/.libs/TestCall_module.so    100755  ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
+/usr/share/doc/python-module-pyorbit-2.24.0/tests/c-inproc/.libs/c-impl.o      100644  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
 /usr/share/doc/python-module-pyorbit-2.24.0/tests/c-inproc/.libs/cTestCall.la  100644  libtool library file
...


3) Cannot make arch package with identical files and deps.
E.g. cannot make arch perl module which should be noarch.

[at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 5
error (#5): perl-Net-IP-1.25-alt2.i586.rpm should be noarch
[at@people 17774]$ 

> If you don't like it, now is the right time to have your say.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] noarch and /usr/share (packages/aptitude: tags/0.4.5-alt5)

[Michael Shigorin]

On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
> 1) Cannot package static binary into noarch package.
> E.g. cannot make cpio-static noarch.

/lib/firmware?

> 2) Arch packages must have identical /usr/share parts.
> E.g. cannot use %doc to package binary files.

id-$random?

> 3) Cannot make arch package with identical files and deps.
> E.g. cannot make arch perl module which should be noarch.

ENOTEPIC

> > If you don't like it, now is the right time to have your say.

Есть мнение, что это очередной набор факультативных вещей,
которые ещё с годик можно попомогать, опираясь на уже
существующие средства (repocop), нежели отрубать шашкой.

Если бы были main и contrib, то для main такие проверки
были бы целесообразны.

Можно тебя попросить посмотреть в сторону _текущих_ проблем
с более чем однокомпонентным репозиторием?  Я помню, что когда-то
были существенными, но с тех пор много воды утекло -- что сейчас?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] noarch and /usr/share (packages/aptitude: tags/0.4.5-alt5)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On Tue, Dec 22, 2009 at 02:12:22PM +0200, Michael Shigorin wrote:
> On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
> > 1) Cannot package static binary into noarch package.
> > E.g. cannot make cpio-static noarch.
> 
> /lib/firmware?

As long as file magic is the same on both arches.
What I was trying to say is that you cannot *compile*
static binaries into noarch packages.  Previously, this
was possible because statically linked executables did not
produce arch-specific dependencies.

> > 2) Arch packages must have identical /usr/share parts.
> > E.g. cannot use %doc to package binary files.
> 
> id-$random?

Not in /usr/share.
Have to use srand() somehow.

> > 3) Cannot make arch package with identical files and deps.
> > E.g. cannot make arch perl module which should be noarch.
> 
> ENOTEPIC

After all, we're low on disk space. :-)

> > > If you don't like it, now is the right time to have your say.
> 
> Есть мнение, что это очередной набор факультативных вещей,
> которые ещё с годик можно попомогать, опираясь на уже
> существующие средства (repocop), нежели отрубать шашкой.

Ну вот сел и закодил.
Мужик проказник работает и в праздник.

> Можно тебя попросить посмотреть в сторону _текущих_ проблем
> с более чем однокомпонентным репозиторием?  Я помню, что когда-то
> были существенными, но с тех пор много воды утекло -- что сейчас?

Что не понятно с более чем однокомпонентным репозиторием?
Компоненты нужно генерировать с опцией --bloat.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
[...]
> http://git.altlinux.org/people/at/packages/girar-builder.git
> 642af655  gb-task-check-noarch-i: force noarch by extensional equality
[...]
> 3) Cannot make arch package with identical files and deps.
> E.g. cannot make arch perl module which should be noarch.
> 
> [at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 5
> error (#5): perl-Net-IP-1.25-alt2.i586.rpm should be noarch

This restriction looks too hard.  How many packages in current
repository would fail to pass the check?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

On Tue, Dec 22, 2009 at 09:18:49PM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
> [...]
> > http://git.altlinux.org/people/at/packages/girar-builder.git
> > 642af655  gb-task-check-noarch-i: force noarch by extensional equality
> [...]
> > 3) Cannot make arch package with identical files and deps.
> > E.g. cannot make arch perl module which should be noarch.
> > 
> > [at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 5
> > error (#5): perl-Net-IP-1.25-alt2.i586.rpm should be noarch
> 
> This restriction looks too hard.  How many packages in current
> repository would fail to pass the check?

Why do you think it's too hard?  Basically, it says "if the list
of files is the same, and ***md5 sums*** are identical, and deps
are identical, the package must be noarch then".

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Damir Shayhutdinov]

> Why do you think it's too hard?  Basically, it says "if the list
> of files is the same, and ***md5 sums*** are identical, and deps
> are identical, the package must be noarch then".
s/must/should/

Re: [devel] forced noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 315 bytes --]

On Tue, Dec 22, 2009 at 10:02:39PM +0300, Damir Shayhutdinov wrote:
> > Why do you think it's too hard?  Basically, it says "if the list
> > of files is the same, and ***md5 sums*** are identical, and deps
> > are identical, the package must be noarch then".
> s/must/should/

Should be coerced into noarch.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[devel] packages with non-identical /usr/share

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 284 bytes --]

On Tue, Dec 22, 2009 at 09:18:49PM +0300, Dmitry V. Levin wrote:
> This restriction looks too hard.  How many packages in current
> repository would fail to pass the check?

Right, let's see what packages are affected.
Here is the first part - packages with non-identical /usr/share.

[-- Attachment #1.2: usr-share.gz --]
[-- Type: application/x-gzip, Size: 10144 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 1122 bytes --]

On Tue, Dec 22, 2009 at 09:18:49PM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
> [...]
> > http://git.altlinux.org/people/at/packages/girar-builder.git
> > 642af655  gb-task-check-noarch-i: force noarch by extensional equality
> [...]
> > 3) Cannot make arch package with identical files and deps.
> > E.g. cannot make arch perl module which should be noarch.
> > 
> > [at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 5
> > error (#5): perl-Net-IP-1.25-alt2.i586.rpm should be noarch
> 
> This restriction looks too hard.  How many packages in current
> repository would fail to pass the check?

Here is the full list of packages which should be made noarch.  Due to
rpm limitations, toplevel packages cannot be made noarch, though (those
are marked with W).

Note that this check does not check if /usr/share parts are identical
(/usr/share parts should be identical by another rule).  To force the
package into noarch, non-/usr/share parts must be exactly the same,
and of course dependencies must be identical, too.

[-- Attachment #1.2: force-noarch.gz --]
[-- Type: application/x-gzip, Size: 9895 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]

On Wed, Dec 23, 2009 at 05:11:47AM +0300, Alexey Tourbin wrote:
> On Tue, Dec 22, 2009 at 09:18:49PM +0300, Dmitry V. Levin wrote:
> > On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
> > [...]
> > > http://git.altlinux.org/people/at/packages/girar-builder.git
> > > 642af655  gb-task-check-noarch-i: force noarch by extensional equality
> > [...]
> > > 3) Cannot make arch package with identical files and deps.
> > > E.g. cannot make arch perl module which should be noarch.
> > > 
> > > [at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 5
> > > error (#5): perl-Net-IP-1.25-alt2.i586.rpm should be noarch
> > 
> > This restriction looks too hard.  How many packages in current
> > repository would fail to pass the check?
> 
> Here is the full list of packages which should be made noarch.

cpuburn-1.4-alt5.i586.rpm should be made noarch?  Do you really think so?

$ zgrep -c ^E force-noarch.gz
892

Isn't it too hard indeed?  Maybe we could patch rpmbuild to make such
packages noarch automatically?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] packages with non-identical /usr/share

[Michael Shigorin]

On Wed, Dec 23, 2009 at 03:49:28AM +0300, Alexey Tourbin wrote:
>  /usr/share/doc/libbakery-devel-2.6.2/examples/Configuration/ConfClient/.libs	40755	directory
>  /usr/share/doc/libcomedi-devel-0.8.1/demo/.libs	40755	directory
>  /usr/share/doc/libguiloader-devel-2.7.1/examples/simple/.libs	40755	directory
>  /usr/share/doc/libiec61883-devel-1.1.0/examples/.libs	40755	directory
>  /usr/share/doc/libmathgl-devel-1.9/examples/.libs	40755	directory
>  /usr/share/doc/libssh2-docs-1.2/example/simple/.libs	40755	directory
>  /usr/share/doc/libvirt-devel-0.7.4/examples/domain-events/events-c/.libs	40755	directory
>  /usr/share/doc/libxspf-devel-1.2.0/examples/check/.libs	40755	directory

Ой.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] noarch and /usr/share (packages/aptitude: tags/0.4.5-alt5)

[Michael Shigorin]

On Tue, Dec 22, 2009 at 08:57:27PM +0300, Alexey Tourbin wrote:
> > Можно тебя попросить посмотреть в сторону _текущих_ проблем
> > с более чем однокомпонентным репозиторием?  Я помню, что когда-то
> > были существенными, но с тех пор много воды утекло -- что сейчас?
> Что не понятно с более чем однокомпонентным репозиторием?

Что нужно, чтоб в сизифе получилось сделать вместо одного classic
на сверхкритичные компоненты и глупые безделушки -- как минимум
main и contrib с возможностью в разной степени закручивать гайки.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] forced noarch

[Damir Shayhutdinov]

> Isn't it too hard indeed?  Maybe we could patch rpmbuild to make such
> packages noarch automatically?

How it can compare the results of two builds for different arches?
It's definitely way above the level of rpm-build, it's overall
repository level, not the single package level.

Re: [devel] forced noarch

[Michael Shigorin]

On Wed, Dec 23, 2009 at 03:38:44PM +0300, Damir Shayhutdinov wrote:
> It's definitely way above the level of rpm-build, it's overall
> repository level, not the single package level.

Interrepo, even.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] forced noarch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Wed, Dec 23, 2009 at 03:38:44PM +0300, Damir Shayhutdinov wrote:
> > Isn't it too hard indeed?  Maybe we could patch rpmbuild to make such
> > packages noarch automatically?
> 
> How it can compare the results of two builds for different arches?

You can make builds for different arches and compare results, can't you?

> It's definitely way above the level of rpm-build, it's overall
> repository level, not the single package level.

The idea is to
- implement noarchification in rpmbuild, and
- implement girar-builder check that noarch build results match.
to minimize dumb work for regular packager.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Damir Shayhutdinov]

>> How it can compare the results of two builds for different arches?
>
> You can make builds for different arches and compare results, can't you?

Using crosscompiling? Now rpm-build will require cross-compiler installed?

Re: [devel] forced noarch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Wed, Dec 23, 2009 at 04:17:04PM +0300, Damir Shayhutdinov wrote:
> >> How it can compare the results of two builds for different arches?
> >
> > You can make builds for different arches and compare results, can't you?
> 
> Using crosscompiling? Now rpm-build will require cross-compiler installed?

There is a good practice to use hasher for builds.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Kirill A. Shutemov]

2009/12/22 Alexey Tourbin <at@altlinux.ru>:
> On Tue, Dec 22, 2009 at 09:18:49PM +0300, Dmitry V. Levin wrote:
>> On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
>> [...]
>> > http://git.altlinux.org/people/at/packages/girar-builder.git
>> > 642af655  gb-task-check-noarch-i: force noarch by extensional equality
>> [...]
>> > 3) Cannot make arch package with identical files and deps.
>> > E.g. cannot make arch perl module which should be noarch.
>> >
>> > [at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 5
>> > error (#5): perl-Net-IP-1.25-alt2.i586.rpm should be noarch
>>
>> This restriction looks too hard.  How many packages in current
>> repository would fail to pass the check?
>
> Why do you think it's too hard?  Basically, it says "if the list
> of files is the same, and ***md5 sums*** are identical, and deps
> are identical, the package must be noarch then".

I don't think that it's a good idea.

There are only two architectures in Sisyphus - i586 and x86_64,
which are similar. It's not enough to be sure, that package is
really noarch.

I think we should postpone the idea untill Sisyphus will have at
least one non-x86 arch and one big-endian arch.

Re: [devel] noarch and /usr/share (packages/aptitude: tags/0.4.5-alt5)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On Wed, Dec 23, 2009 at 02:00:51PM +0200, Michael Shigorin wrote:
> On Tue, Dec 22, 2009 at 08:57:27PM +0300, Alexey Tourbin wrote:
> > > Можно тебя попросить посмотреть в сторону _текущих_ проблем
> > > с более чем однокомпонентным репозиторием?  Я помню, что когда-то
> > > были существенными, но с тех пор много воды утекло -- что сейчас?
> > Что не понятно с более чем однокомпонентным репозиторием?
> 
> Что нужно, чтоб в сизифе получилось сделать вместо одного classic
> на сверхкритичные компоненты и глупые безделушки -- как минимум
> main и contrib с возможностью в разной степени закручивать гайки.

Не факт что это можно делать автоматически.  Требования замкнутости
там не совсем тривиальные.  Хотелось бы также иметь non-free.  (Но тут
как раз выясняется что free будет зависеть от non-free, если java всего
одна, а если джавов несколько то с ходу очень трудно сказать как там
зависимости могут переплестись.)

В общем это требует ручной работы, хотя бо время от времени.  В своё
время inger'у был интересно отделять мух от котлет, он сидел и отделял.
Ещё в свое время он работал incominger'ом -- собирал на своей машине
входящие пакеты, проверял их и отправлял в сизиф.  Unbelievable.
Потом ему естественно надоело, и всё кончилось тем, что сделали classic.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

On Wed, Dec 23, 2009 at 04:17:09PM +0200, Kirill A. Shutemov wrote:
> 2009/12/22 Alexey Tourbin <at@altlinux.ru>:
> > On Tue, Dec 22, 2009 at 09:18:49PM +0300, Dmitry V. Levin wrote:
> >> On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
> >> [...]
> >> > http://git.altlinux.org/people/at/packages/girar-builder.git
> >> > 642af655  gb-task-check-noarch-i: force noarch by extensional equality
> >> [...]
> >> > 3) Cannot make arch package with identical files and deps.
> >> > E.g. cannot make arch perl module which should be noarch.
> >> >
> >> > [at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 5
> >> > error (#5): perl-Net-IP-1.25-alt2.i586.rpm should be noarch
> >>
> >> This restriction looks too hard.  How many packages in current
> >> repository would fail to pass the check?
> >
> > Why do you think it's too hard?  Basically, it says "if the list
> > of files is the same, and ***md5 sums*** are identical, and deps
> > are identical, the package must be noarch then".
> 
> I don't think that it's a good idea.
> 
> There are only two architectures in Sisyphus - i586 and x86_64,
> which are similar. It's not enough to be sure, that package is
> really noarch.

Can you specify a package (from the list) which is identical on i586
and x86_64, but should not be made noarch because it assumes e.g.
little-endian architecture?

> I think we should postpone the idea untill Sisyphus will have at
> least one non-x86 arch and one big-endian arch.

i586 and x86_64 are "different enough" except for endianness.
Look how they are different:
1) file paths are different (lib - lib64);
2) native binaries are different (elf32 - elf64);
3) sizeof(void*) == sizeof(long) is different.

How they are common:
1) sizeof(int) is the same (32 bit),
2) both are little endian.
Which means that certain host data structures (and thus certain binary
file formats) might have the same representation.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3813 bytes --]

On Wed, Dec 23, 2009 at 02:12:53PM +0300, Dmitry V. Levin wrote:
> > Here is the full list of packages which should be made noarch.
> cpuburn-1.4-alt5.i586.rpm should be made noarch?  Do you really think so?

[at@people at]$ rpmquery --qf '[%{FILENAMES}\t%{FILEMD5S}\n]' -p /ALT/Sisyphus/files/i586/RPMS/cpuburn-1.4-alt5.i586.rpm 
/usr/bin/burnBX 3963165dea4eceac2ad550c2ebe9e93e
/usr/bin/burnK6 b72d685d7beed398bccd0a56f7c36d1a
/usr/bin/burnK7 6be9eabb21b8482f3e3261e2af0de188
/usr/bin/burnMMX        0050bf8ac72ba7f3187a2830f05cc340
/usr/bin/burnP5 d10fbf78fb2396c02e2a1022641796e1
/usr/bin/burnP6 13e1dd053a0c5e77f08d8cc0af2fe898
/usr/share/doc/cpuburn-1.4      
/usr/share/doc/cpuburn-1.4/Design       94eb3d0c7095d10b7c670545e211b767
/usr/share/doc/cpuburn-1.4/README       92aa364c1942f0396bb7c99a91b2bf88
[at@people at]$ rpmquery --qf '[%{FILENAMES}\t%{FILEMD5S}\n]' -p /ALT/Sisyphus/files/x86_64/RPMS/cpuburn-1.4-alt5.x86_64.rpm 
/usr/bin/burnBX 3963165dea4eceac2ad550c2ebe9e93e
/usr/bin/burnK6 b72d685d7beed398bccd0a56f7c36d1a
/usr/bin/burnK7 6be9eabb21b8482f3e3261e2af0de188
/usr/bin/burnMMX        0050bf8ac72ba7f3187a2830f05cc340
/usr/bin/burnP5 d10fbf78fb2396c02e2a1022641796e1
/usr/bin/burnP6 13e1dd053a0c5e77f08d8cc0af2fe898
/usr/share/doc/cpuburn-1.4      
/usr/share/doc/cpuburn-1.4/Design       94eb3d0c7095d10b7c670545e211b767
/usr/share/doc/cpuburn-1.4/README       92aa364c1942f0396bb7c99a91b2bf88
[at@people at]$ 

[at@people at]$ rpmfile /ALT/Sisyphus/files/x86_64/RPMS/cpuburn-1.4-alt5.x86_64.rpm
/usr/bin/burnBX 100755  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
/usr/bin/burnK6 100755  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
/usr/bin/burnK7 100755  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
/usr/bin/burnMMX        100755  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
/usr/bin/burnP5 100755  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
/usr/bin/burnP6 100755  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
/usr/share/doc/cpuburn-1.4      40755   directory
/usr/share/doc/cpuburn-1.4/Design       100644  ASCII English text
/usr/share/doc/cpuburn-1.4/README       100644  ASCII English text
[at@people at]$ 

cpuburn.spec:
%define cpulist P6 BX K6 K7 MMX P5
for n in %cpulist; do
        gcc -m32 -Wa,--noexecstack -nostdlib -o burn$n burn$n.S
done

Hmm, so you build the same *.S files, and basically you should have the
same binaries on all architectures.  (But there is also ExclusiveArch
there...)

> $ zgrep -c ^E force-noarch.gz
> 892

That's around 600 source packages.

[at@people at]$ zgrep ^E force-noarch.gz |cut -f2 |(cd /ALT/Sisyphus/files/i586/RPMS/; xargs rpmquery --qf '%{SOURCERPM}\n' -p) |sort -u |wc -l
error: open of qemu-kvm-vde-0.11.1-alt5.i586.rpm failed: No such file or directory
error: open of sysstat-isag-9.0.4-alt1.i586.rpm failed: No such file or directory
601
[at@people at]$ 

> Isn't it too hard indeed?  Maybe we could patch rpmbuild to make such
> packages noarch automatically?

rpmbuild itself cannot decide whether certain packages should be noarch.
Consider my previous example with perl-Net-IP-1.25-alt3.noarch.rpm (yeah,
it's been fixed).  It contains /usr/lib/perl5/vendor_perl/Net/IP.pm.
This is plain text file, but since it is under /usr/lib, we cannot
automatically decide whether it's good for noarch (e.g. it might have
platform-specific paths hardcoded into it).  So, to decide whether IP.pm
is good enough for noarch, we should build the package on both
architectures and ensure that IP.pm is exactly the same.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Kirill A. Shutemov]

2009/12/23 Alexey Tourbin <at@altlinux.ru>:
> On Wed, Dec 23, 2009 at 04:17:09PM +0200, Kirill A. Shutemov wrote:
>> 2009/12/22 Alexey Tourbin <at@altlinux.ru>:
>> > On Tue, Dec 22, 2009 at 09:18:49PM +0300, Dmitry V. Levin wrote:
>> >> On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
>> >> [...]
>> >> > http://git.altlinux.org/people/at/packages/girar-builder.git
>> >> > 642af655  gb-task-check-noarch-i: force noarch by extensional equality
>> >> [...]
>> >> > 3) Cannot make arch package with identical files and deps.
>> >> > E.g. cannot make arch perl module which should be noarch.
>> >> >
>> >> > [at@people 17774]$ PATH=~/git.alt/girar-builder:$PATH gb-task-check-noarch-i 5
>> >> > error (#5): perl-Net-IP-1.25-alt2.i586.rpm should be noarch
>> >>
>> >> This restriction looks too hard.  How many packages in current
>> >> repository would fail to pass the check?
>> >
>> > Why do you think it's too hard?  Basically, it says "if the list
>> > of files is the same, and ***md5 sums*** are identical, and deps
>> > are identical, the package must be noarch then".
>>
>> I don't think that it's a good idea.
>>
>> There are only two architectures in Sisyphus - i586 and x86_64,
>> which are similar. It's not enough to be sure, that package is
>> really noarch.
>
> Can you specify a package (from the list) which is identical on i586
> and x86_64, but should not be made noarch because it assumes e.g.
> little-endian architecture?

At least all packages which contain GNU message catalog files(*.mo):

$ for p in `cat ~/tmp/force-noarch`; do rpm -qpl $p | grep -q
'^/usr/share/locale/.*\.mo' && echo $p ; done
bison-runtime-2.4.1-alt2.i586.rpm
celestia-common-1.6.0-alt4.i586.rpm
comix-4.0.4-alt1.1.i586.rpm
gftp-common-2.0.18stable-alt5.i586.rpm
gkrellm-ss-common-2.6-alt1.i586.rpm
gnome-utils-common-2.28.1-alt2.i586.rpm
gramps-3.1.2-alt1.1.i586.rpm
gwenview-i18n-1.4.2-alt1.i586.rpm
installer-ltsp-0.1-alt2.5.7.i586.rpm
installer-ltsp-school-0.4-alt5.3.i586.rpm
installer-server-0.2-alt2.i586.rpm
installer-server-lite-0.2-alt1.i586.rpm
libgtk-engines-default-common-2.18.4-alt1.i586.rpm
remount_rw-0.2-alt1.i586.rpm
sugar-pippy-activity-25-alt3.1.i586.rpm
virt-manager-0.8.2-alt2.i586.rpm

Who knows what else.

>> I think we should postpone the idea untill Sisyphus will have at
>> least one non-x86 arch and one big-endian arch.
>
> i586 and x86_64 are "different enough" except for endianness.
> Look how they are different:
> 1) file paths are different (lib - lib64);
> 2) native binaries are different (elf32 - elf64);
> 3) sizeof(void*) == sizeof(long) is different.
>
> How they are common:
> 1) sizeof(int) is the same (32 bit),
> 2) both are little endian.
> Which means that certain host data structures (and thus certain binary
> file formats) might have the same representation.

Re: [devel] forced noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Wed, Dec 23, 2009 at 10:33:37PM +0200, Kirill A. Shutemov wrote:
> > Can you specify a package (from the list) which is identical on i586
> > and x86_64, but should not be made noarch because it assumes e.g.
> > little-endian architecture?
> 
> At least all packages which contain GNU message catalog files(*.mo):

It's a well-known special case: little-endian and big-endian *.mo files
can be used interchangeably (with small overhead for non-native byte
order).  Otherwise we can't put them under /usr/share in the first place!

> $ for p in `cat ~/tmp/force-noarch`; do rpm -qpl $p | grep -q
> '^/usr/share/locale/.*\.mo' && echo $p ; done

> Who knows what else.

Dmitry Levin pointed out the cpuburn package...

> > i586 and x86_64 are "different enough" except for endianness.
> > Look how they are different:
> > 1) file paths are different (lib - lib64);
> > 2) native binaries are different (elf32 - elf64);
> > 3) sizeof(void*) == sizeof(long) is different.
> >
> > How they are common:
> > 1) sizeof(int) is the same (32 bit),
> > 2) both are little endian.
> > Which means that certain host data structures (and thus certain binary
> > file formats) might have the same representation.

... which gives another "bad similarity" between the two platforms:
3) Though native binaries are different, x86_64 can execute i586 code
"almost natively", and x86_64 gcc has limited support for compiling
i586 code.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Wed, Dec 23, 2009 at 11:11:00PM +0300, Alexey Tourbin wrote:
> On Wed, Dec 23, 2009 at 02:12:53PM +0300, Dmitry V. Levin wrote:
> > Isn't it too hard indeed?  Maybe we could patch rpmbuild to make such
> > packages noarch automatically?
> 
> rpmbuild itself cannot decide whether certain packages should be noarch.
> Consider my previous example with perl-Net-IP-1.25-alt3.noarch.rpm (yeah,
> it's been fixed).  It contains /usr/lib/perl5/vendor_perl/Net/IP.pm.
> This is plain text file, but since it is under /usr/lib, we cannot
> automatically decide whether it's good for noarch (e.g. it might have
> platform-specific paths hardcoded into it).  So, to decide whether IP.pm
> is good enough for noarch, we should build the package on both
> architectures and ensure that IP.pm is exactly the same.

There's another option: to coerce packages into noarch posthumously.
Which is to rename .i586.rpm -> .noarch.rpm and to edit the header.
This will require girar-builder redesign, but it seems doable.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forced noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

On Thu, Dec 24, 2009 at 01:30:27AM +0300, Alexey Tourbin wrote:
> On Wed, Dec 23, 2009 at 11:11:00PM +0300, Alexey Tourbin wrote:
> > On Wed, Dec 23, 2009 at 02:12:53PM +0300, Dmitry V. Levin wrote:
> > > Isn't it too hard indeed?  Maybe we could patch rpmbuild to make such
> > > packages noarch automatically?
> > 
> > rpmbuild itself cannot decide whether certain packages should be noarch.
> > Consider my previous example with perl-Net-IP-1.25-alt3.noarch.rpm (yeah,
> > it's been fixed).  It contains /usr/lib/perl5/vendor_perl/Net/IP.pm.
> > This is plain text file, but since it is under /usr/lib, we cannot
> > automatically decide whether it's good for noarch (e.g. it might have
> > platform-specific paths hardcoded into it).  So, to decide whether IP.pm
> > is good enough for noarch, we should build the package on both
> > architectures and ensure that IP.pm is exactly the same.
> 
> There's another option: to coerce packages into noarch posthumously.
> Which is to rename .i586.rpm -> .noarch.rpm and to edit the header.
> This will require girar-builder redesign, but it seems doable.

So let's make more noarch packages before I get drunk^W^W
switch to Natalie Portman!

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forcing arch/noarch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
> On Tue, Dec 22, 2009 at 02:36:16AM +0300, Alexey Tourbin wrote:
[...]
> > I think I am going to implement much stricter checking for both noarch
> > packages and /usr/share part of arch packages.  Also, I am going to
> > implement new "force-noarch" check which will require some packages
> > be noarch (by the principle of "extensional equality").
> 
> http://git.altlinux.org/people/at/packages/girar-builder.git
> 642af655  gb-task-check-noarch-i: force noarch by extensional equality
> 9bce38b3  gb-task-check-noarch-i: check for identical /usr/share part in arch pacakges
> 60af4a7c  gb-task-check-noarch-i: use rpmfile(1) to check noarch cpio contents
> 67f83c43  gb-task-check-noarch-i: use ls again
> 17d6d4ea  gb-task-check-noarch, gb-task-check-noarch-i: factored from gb-task-check-build-i

Let's summarise the discussion and decide what shall we do with it.

The proposed patchset introduces two new restrictions:
1. Packages that mustn't be noarch because of essential payload
   mismatch on different architectures.
2. Packages that must be noarch because their payload is essentially
   the same on different architectures.

The only drawback of the first restriction is that the proposed
implementation fails to filter out non-essential differences, e.g.
timestamps and random html reference names.  That is, in its current
form it would stop some grave packaging bugs, but also it would forbid
some legal noarch packages.

The second restriction was reported to have a major impact on packages
because it affects about 600 source packages, and changing rules to
break so many packages due to optimization purposes doesn't look good.
Some ideas to avoid extra dumb work for packages were proposed later,
but no implementation have been arisen yet.
Also, the implementation in its current form may mistakenly decide that
packages have to be noarch while they really shouldn't, e.g. cpuburn.

That is, I'd be glad to make these restrictions taken effect when these
three issues are dealt with.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forcing arch/noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3617 bytes --]

On Sun, Dec 27, 2009 at 04:09:38AM +0300, Dmitry V. Levin wrote:
> On Tue, Dec 22, 2009 at 11:05:56AM +0300, Alexey Tourbin wrote:
> > On Tue, Dec 22, 2009 at 02:36:16AM +0300, Alexey Tourbin wrote:
> [...]
> > > I think I am going to implement much stricter checking for both noarch
> > > packages and /usr/share part of arch packages.  Also, I am going to
> > > implement new "force-noarch" check which will require some packages
> > > be noarch (by the principle of "extensional equality").
> > 
> > http://git.altlinux.org/people/at/packages/girar-builder.git
> > 642af655  gb-task-check-noarch-i: force noarch by extensional equality
> > 9bce38b3  gb-task-check-noarch-i: check for identical /usr/share part in arch pacakges
> > 60af4a7c  gb-task-check-noarch-i: use rpmfile(1) to check noarch cpio contents
> > 67f83c43  gb-task-check-noarch-i: use ls again
> > 17d6d4ea  gb-task-check-noarch, gb-task-check-noarch-i: factored from gb-task-check-build-i
> 
> Let's summarise the discussion and decide what shall we do with it.
> 
> The proposed patchset introduces two new restrictions:
> 1. Packages that mustn't be noarch because of essential payload
>    mismatch on different architectures.

Furthermore, /usr/share part of arch-dependent packages is treated
the same way as noarch packages.  This is how you can detect binaries
under /usr/share/doc.

> 2. Packages that must be noarch because their payload is essentially
>    the same on different architectures.
> 
> The only drawback of the first restriction is that the proposed
> implementation fails to filter out non-essential differences, e.g.
> timestamps and random html reference names.  That is, in its current
> form it would stop some grave packaging bugs, but also it would forbid
> some legal noarch packages.

This depends on how you define "legal".  At an extreme, it is best to
require full md5 match for both noarch packages and /usr/share part of
arch packages.  However, we need to omit mtime.  This might not be easy
since some files can include mtime (e.g. *.jar files) but otherwise have
identical contents (and in case of *.jar files, mtime is not even part
of the "contents").

So we simply can't require full md5 match before we can handle *.jar
files.  So, for now, to use file(1) seems to be the right thing to do.

> The second restriction was reported to have a major impact on packages
> because it affects about 600 source packages, and changing rules to
> break so many packages due to optimization purposes doesn't look good.
> Some ideas to avoid extra dumb work for packages were proposed later,
> but no implementation have been arisen yet.
> Also, the implementation in its current form may mistakenly decide that
> packages have to be noarch while they really shouldn't, e.g. cpuburn.
> 
> That is, I'd be glad to make these restrictions taken effect when these
> three issues are dealt with.

So "the three issues" are:
1a) Different filenames in noarch packages - to me, illegal.
And that's not new.  Only treating /usr/share the same way is new.
1b) Non-essential differences between files - we use only file magic
instead of full md5 match (also, fixed gzip magic to exclude mtime).
2) Too many packages will fail to pass the girar.
3) False noarch due to i586 running on x86_64.

I guess we can agree upon downgrading to warnings.  But warnings
don't work as good as errors.  How many times you think you've seen
the warning about /usr/share/doc/liboil-0.3.16 ?

Results 1 - 50 of 50 from lists.altlinux.org for "/usr/share/doc/liboil-0.3".

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forcing arch/noarch

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Sun, Dec 27, 2009 at 04:53:52AM +0300, Алексей Турбин wrote:

AT> I guess we can agree upon downgrading to warnings.  But warnings
AT> don't work as good as errors.  How many times you think you've seen
AT> the warning about /usr/share/doc/liboil-0.3.16 ?
AT> Results 1 - 50 of 50 from lists.altlinux.org for "/usr/share/doc/liboil-0.3".

У нас еще есть repocop.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] forcing arch/noarch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 4326 bytes --]

On Sun, Dec 27, 2009 at 04:53:52AM +0300, Alexey Tourbin wrote:
> On Sun, Dec 27, 2009 at 04:09:38AM +0300, Dmitry V. Levin wrote:
[...]
> > The proposed patchset introduces two new restrictions:
> > 1. Packages that mustn't be noarch because of essential payload
> >    mismatch on different architectures.
> 
> Furthermore, /usr/share part of arch-dependent packages is treated
> the same way as noarch packages.

Yes, and this might be a problem for packagers.
For example, eclipse-ecj isn't a noarch package but
/usr/share/java/eclipse-ecj-3.4.1.jar symlink points to
%_libdir/eclipse/dropins/jdt/plugins/org.eclipse.jdt.core_3.4.2.v_883_R34x.jar
That is, the whole package needs to be reworked.  This task might be quite
complicated because /usr/share/java/ecj.jar is referenced by other
packages.  I'm not sure that we are ready for this restriction yet.

> This is how you can detect binaries under /usr/share/doc.

Yes, but there are other methods to implement such a detection.

> > 2. Packages that must be noarch because their payload is essentially
> >    the same on different architectures.
> > 
> > The only drawback of the first restriction is that the proposed
> > implementation fails to filter out non-essential differences, e.g.
> > timestamps and random html reference names.  That is, in its current
> > form it would stop some grave packaging bugs, but also it would forbid
> > some legal noarch packages.
> 
> This depends on how you define "legal".  At an extreme, it is best to
> require full md5 match for both noarch packages and /usr/share part of
> arch packages.  However, we need to omit mtime.  This might not be easy
> since some files can include mtime (e.g. *.jar files) but otherwise have
> identical contents (and in case of *.jar files, mtime is not even part
> of the "contents").

I'd say that noarch packages built on different platforms are equivalent
if one could be substituted with another without changing behaviour.

For example, different timestamps are OK if nothing depends on them.
Even different file names are probably OK if they behave the same way
and if they aren't referenced by other packages (it would be hard to
prove that they aren't referenced, though).

> So we simply can't require full md5 match before we can handle *.jar
> files.  So, for now, to use file(1) seems to be the right thing to do.

Timestamps are sometimes included in file(1) output.  The first hunk from
your usr-share.gz demonstrates this:

-/usr/share/doc/SNNS-Manual-4.2/UserManual.dvi	100644	TeX DVI file (TeX output 2009.10.08:2318\213
+/usr/share/doc/SNNS-Manual-4.2/UserManual.dvi	100644	TeX DVI file (TeX output 2009.10.08:2317\213

> > The second restriction was reported to have a major impact on packages
> > because it affects about 600 source packages, and changing rules to
> > break so many packages due to optimization purposes doesn't look good.
> > Some ideas to avoid extra dumb work for packages were proposed later,
> > but no implementation have been arisen yet.
> > Also, the implementation in its current form may mistakenly decide that
> > packages have to be noarch while they really shouldn't, e.g. cpuburn.
> > 
> > That is, I'd be glad to make these restrictions taken effect when these
> > three issues are dealt with.
> 
> So "the three issues" are:
> 1a) Different filenames in noarch packages - to me, illegal.
> And that's not new.  Only treating /usr/share the same way is new.
> 1b) Non-essential differences between files - we use only file magic
> instead of full md5 match (also, fixed gzip magic to exclude mtime).

TeX DVI file magic needs similar fix.

> 2) Too many packages will fail to pass the girar.

Yes.

> 3) False noarch due to i586 running on x86_64.

I believe these false positives could be dealt with.
For example, packages with exclusivearch/excludearch shouldn't be forced
to noarch.

> I guess we can agree upon downgrading to warnings.  But warnings
> don't work as good as errors.  How many times you think you've seen
> the warning about /usr/share/doc/liboil-0.3.16 ?

Yes, warnings are almost of no use.  In particular, too little attention
is being paid to repocop warnings.  But vast number of new errors is not
good, too.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[devel] suggesting arch/noarch

[Michael Shigorin]

On Sun, Dec 27, 2009 at 04:53:52AM +0300, Alexey Tourbin wrote:
> At an extreme, it is best to require full md5 match for both
> noarch packages and /usr/share part of arch packages.

А это зависит от определения "best".

Напоминаю, что если думать не о людях, а о чём-то ещё,
то людям рано или поздно станет неуютно и останется
самоудовлетворяться об протухший и никому не нужный
каталог с файликами.

noarch -- это то, что годится в работу вне зависимости
от архитектуры.  Необязательно ещё и собирается идентичным
на любой: это уже примерно как ровнять заодно налоговый кодекс.

Пожалуйста, используй это определение или раскритикуй
и предложи иное, с которым согласятся люди.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] suggesting arch/noarch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Mon, Dec 28, 2009 at 07:23:34PM +0200, Michael Shigorin wrote:
> On Sun, Dec 27, 2009 at 04:53:52AM +0300, Alexey Tourbin wrote:
> > At an extreme, it is best to require full md5 match for both
> > noarch packages and /usr/share part of arch packages.
> 
> А это зависит от определения "best".
> 
> Напоминаю, что если думать не о людях, а о чём-то ещё,
> то людям рано или поздно станет неуютно и останется
> самоудовлетворяться об протухший и никому не нужный
> каталог с файликами.

Людишки очень тупы, думать про них смысла нет.

> noarch -- это то, что годится в работу вне зависимости
> от архитектуры.  Необязательно ещё и собирается идентичным
> на любой: это уже примерно как ровнять заодно налоговый кодекс.
> 
> Пожалуйста, используй это определение или раскритикуй
> и предложи иное, с которым согласятся люди.

Твое определение по сути верно, но как убедиться, что оно выполняется?
Когда md5-суммы совпадают, то есть гарантия, что условие выполняется.
А когда md5-суммы не совпадают, то никакой гарантии нет, и, более того,
выполнятся определение или нет проверить никак нельзя.

Это получается вроде принципа Барбары Лисков.  Принцип конечно
интересный чтобы чисто порассуждать, но когда у тебя на руках простыня
кода то понять выполняется этот принцип или нет практически никакой
возможности нету.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]