Re: [devel] forcing arch/noarch

["Dmitry V. Levin" <ldv@altlinux.org>]

[-- 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 --]