Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk

[Stefan van der Eijk]

Otherwise we'll have a dead symlink in /usr/lib, which points to the .so symlink in /lib.

Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so symlinks.

Fine with me, as long as xfsdump will build.

And I insist on %{_lib} & %{_libdir}. I had fixed that for lib64 but this magically vanished.

Yes, I agree. Sorry about that.

Any objections to updating xfsdump to 2.2.3?

I don't know, kernel people will answer. And I suppose Vincent already issued an update to 2.2.3.

BuildRequires: libattr-devel
BuildRequires: libdm-devel
BuildRequires: libext2fs-devel
BuildRequires: libxfs-devel

Always BuildRequires: <thing>-devel forms only, not lib<thing>-devel.

Sure, but:

$ urpmq attr-devel
no package named attr-devel

$ urpmq dm-devel
no package named dm-devel

$ urpmq ext2fs-devel
no package named ext2fs-devel

$ urpmq xfs-devel
no package named xfs-devel

I understand where this is coming from, and I agree that it needs to be done. But I don't think that it needs to be brought up in this discussion. I'm getting the feeling that somebody is looking for something to pick on...

I suggest:

   *  rpmlint is adjusted to warn about (& enforce?) this on uploads;
   * a document is written describing these changes so this can be
     finalized into some sort of  guideline / policy. So people can
     read it through, understand how it works and how it should be
     implemented in the packages;

For instance: I don't understand how the mklib stuff works and how I should fix the rpmlint errors I get on the topic.

regards,

Stefan

smime.p7s
Description: S/MIME Cryptographic Signature