Re: How is RPMTAG_FILELINKTOS filled?

2008-10-28 Thread devzero2000
On Tue, Oct 28, 2008 at 5:54 PM, Jeff Johnson [EMAIL PROTECTED] wrote:


 On Oct 28, 2008, at 12:36 PM, Eric MSP Veith wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 while creating a package, I renamed in the %install section a bunch of
 manpages by changing their extension from e. g. 1 to 1ssl. RPM-5.1.6
 creates an implicit dependency for each renamed manpage.

 I got curious on what (1) causes the dependency generation (it is not a
 (symbolic|hard) link, just a regular file), what (2) actually triggers the
 dependency generation and how (3) to avoid it.

 I tried digging through the source code, but I got completely lost. So I
 wrote this message to the ML.

 Thanks in advance!


 What is conceptiually confusing aboy filelinktos (and parentdir)
 dependencies is that there is no change to package metadata content
 whatsoever.

 What is being done internally to rpm during install
 is to take RPMTAG_FILELINKTOS (and RPMTAG_DIRNAMES)
 string arrays and wrap the contents as if Requires: had been
 added to the spec file originally.

 No matter how hard you look, you will not find any additional
 metadata, its in the implementation.

 Add --noparentdirs and --nolinktos to disable the dependencies.

 The only remaining issue is what the default in rpm should be.



Just an opinion on the file linkto and parentdirs deps, already posed in
other forms
some time ago (http://rpm5.org/community/rpm-devel/2374.html)

For me it is a feature of rpm5 and not a incompatibility: for example
other, that don't have this feature
only define the guideline but don't impose then (
https://fedoraproject.org/wiki/Packaging/UnownedDirectories).


Being a feature could be the case for rpm5, to fullfill automatically but
giving warning at installation time , of  /etc/rpm/sysinfo/Dirnames
and /etc/rpm/sysinfo/Filelinktos. Perhaps a rpm macros could be necessary
for enable/disable this behaviour. Look like a RFE or a plan ?

Opinions ?






 Since I might as well not have done the implementation (as with
 --nosignatures and --nodigests disablers) if the default setting
 is always and routinely turned off, I choose to distribute
 rpm with the functionality enabled.

 Exercise left to lusers to find how to disable the functionality.

 Hint: its very not hard.

 73 de Jeff

 __
 RPM Package Managerhttp://rpm5.org
 User Communication List [EMAIL PROTECTED]



Re: [CVS] RPM: rpm/ CHANGES VENDOR rpm/lib/ depends.c

2008-10-28 Thread devzero2000
Could be better also to fullfill automatically /etc/rpm/sysinfo/Dirname e
Filelinkto, giving an hint to the user ? In this case there is the
possibilty to catch this packaging error and to improve the quality of the
system -- and the distro.

Regards



On Tue, Oct 28, 2008 at 4:25 PM, Per Øyvind Karlsen [EMAIL PROTECTED]wrote:

  RPM Package Manager, CVS Repository
  http://rpm5.org/cvs/

  

  Server: rpm5.org Name:   Per Øyvind Karlsen
  Root:   /v/rpm/cvs   Email:  [EMAIL PROTECTED]
  Module: rpm  Date:   28-Oct-2008 16:25:20
  Branch: HEAD Handle: 2008102815251901

  Modified files:
rpm CHANGES VENDOR
rpm/lib depends.c

  Log:
Mandriva: make directory  symlink dependencies optional with
 %{_check_symlink_deps}
 %{_check_dirname_deps}. (optional-dirname-and-symlink-deps)

  Summary:
RevisionChanges Path
1.2636  +2  -0  rpm/CHANGES
2.61+14 -1  rpm/VENDOR
1.424   +16 -0  rpm/lib/depends.c

  

  patch -p0 '@@ .'
  Index: rpm/CHANGES

  
  $ cvs diff -u -r1.2635 -r1.2636 CHANGES
  --- rpm/CHANGES   28 Oct 2008 14:19:44 -  1.2635
  +++ rpm/CHANGES   28 Oct 2008 15:25:19 -  1.2636
  @@ -1,5 +1,7 @@

   5.2a2 - 5.2a3:
  +- proyvind: Mandriva: make directory  symlink dependencies optional
 with
  +%{_check_symlink_deps}  %{_check_dirname_deps}.
 (optional-dirname-and-symlink-deps)
   - proyvind: Mandriva: prefer file extension for detecting file
 compression.
   (extension-based-compression-detection)
   - proyvind: Mandriva: disable buildrequires checking for building
 src.rpms.
  @@ .
  patch -p0 '@@ .'
  Index: rpm/VENDOR

  
  $ cvs diff -u -r2.60 -r2.61 VENDOR
  --- rpm/VENDOR28 Oct 2008 14:19:44 -  2.60
  +++ rpm/VENDOR28 Oct 2008 15:25:19 -  2.61
  @@ -514,7 +514,7 @@
Change: no-deps-on-building-srpms
Purpose:Do not perform any dependency checking on building
 SRPMs.
Reason: Don't really need this as 'digest(...)' and friends
 hasn't
  - been put to use (yet), making this just annoying.
  + been put to use (so far), making this just annoying.

  

Change: extension-based-compression-detection
  @@ -531,6 +531,19 @@
detecting LZMA we want to do via file extension
 only.

  

  + Change: optional-dirname-and-symlink-deps
  + Purpose:Optional dependencies on symlinks and parent
 directories.
  + Reason: Mandriva doesn't store file lists in it's standard
  + synthesis metadata, resulting in any dependencies on
 these
  + not met during installation fail. Also always
 enforcing
  + these dependencies on third party packages which
 rarely
  + complies with distro policies, is of varying quality
 wrt.
  + quality and what not will also often lead to these
 having
  + files in directories not owned etc. Also in the case
 of
  + usage on systems not primarily using rpm, this will
  + ~always be an issue.
  +
 
  +
 o  Name:   WINDRIVER
Vendor: Wind River http://windriver.com/
Representative: Jeff Johnson [EMAIL PROTECTED]
  @@ .
  patch -p0 '@@ .'
  Index: rpm/lib/depends.c

  
  $ cvs diff -u -r1.423 -r1.424 depends.c
  --- rpm/lib/depends.c 27 Oct 2008 13:18:15 -  1.423
  +++ rpm/lib/depends.c 28 Oct 2008 15:25:20 -  1.424
  @@ -1551,6 +1551,10 @@
   int terminate = 2;   /* XXX terminate if rc = terminate
 */
   int rc;
   int ourrc = 0;
  +#if defined(RPM_VENDOR_MANDRIVA) /* optional-dirname-and-symlink-deps */
  +int dirname_deps;
  +int symlink_deps;
  +#endif

   requires = rpmdsInit(requires);
   if (requires != NULL)
  @@ -1626,6 +1630,10 @@
}
   }

  +#if defined(RPM_VENDOR_MANDRIVA) /* optional-dirname-and-symlink-deps */
  +dirname_deps =
 rpmExpandNumeric(%{?_check_dirname_deps}%{?!_check_dirname_deps:1});
  +if (dirname_deps) {
  +#endif
   dirnames = rpmdsInit(dirnames);
   if (dirnames != 

Re: [CVS] RPM: rpm/ CHANGES VENDOR rpm/lib/ depends.c

2008-10-28 Thread Per Øyvind Karlsen
2008/10/28 devzero2000 [EMAIL PROTECTED]

 Could be better also to fullfill automatically /etc/rpm/sysinfo/Dirname e
 Filelinkto, giving an hint to the user ? In this case there is the
 possibilty to catch this packaging error and to improve the quality of the
 system -- and the distro.

Enabling it would sure help to spot these and improve package quality in the
distro, but as the distro isn't really using this and not all that much
attention
are paid to these things, fixing every single issue I come across would lead
to much work for me doing janitor work..

So that's why I leave it optional in stead of disabling it completely, I
intend to deal with this in some way eventually/occationaly. :)
--
Regards,
Per Øyvind


Re: [CVS] RPM: rpm/ CHANGES VENDOR rpm/lib/ depends.c

2008-10-28 Thread Jeff Johnson


On Oct 28, 2008, at 3:46 PM, Per Øyvind Karlsen wrote:


2008/10/28 devzero2000 [EMAIL PROTECTED]
Could be better also to fullfill automatically /etc/rpm/sysinfo/ 
Dirname e Filelinkto, giving an hint to the user ? In this case  
there is the possibilty to catch this packaging error and to improve  
the quality of the system -- and the distro.
Enabling it would sure help to spot these and improve package  
quality in the distro, but as the distro isn't really using this and  
not all that much attention
are paid to these things, fixing every single issue I come across  
would lead to much work for me doing janitor work..


So that's why I leave it optional in stead of disabling it  
completely, I intend to deal with this in some way eventually/ 
occationaly. :)


FWIW: There is a --orphandirs option to assist with initially populating
the Dirnames masking (until vendors get around to fixing their  
packages).


All that's needed to mask the pain of parentdir dependencies is to do
mkdir -p /etc/rpm/sysinfo
rpm -V --orphandors  /etc/rpm/sysinfo/Dirnames
immediately after installing rpm-4.4.7 (or later, including rpm-5.x)

Pain with filelinktos deps is several orders of magnitude smaller than
with parentdir dependencies, so I did not bother adding a popt alias
like --orpandirs to jumpstart supplying symlink end-point dependencies.

After populating /etc/rpm/sysinfoDirnames, I find (but YMMV) that the  
manual effort involved with editing in additional orphan directory  
paths into /etc/rpm/sysinfo/Dirnames when, say, an upgrade to a  
package adds new orphan directories to be quite modest and acceptable.


Sure annoying, but using rpm is always annoying. ;-)

Maintaining the list of orphandirs automagically is certainly doable.

OTOH, the packages, not rpm, are what really need fixing. Automagically
maintaining a list of orphan directory paths automagically is unlikely
to fix *.rpm packages this decade imho.

As much as I hate nag ware, any utility gain by automagically  
maintaining a list of orphan directories by rpm hardly seems worth the  
implementation effort. Improving the quality
of *.rpm packages is the goal, consistent policies for how to package  
directories correctly

have never been completely specified afaik.

Note that the issue of orphan directories has a huge and complicated  
history.


The problem was (quite correctly imho) diagnosed by Enrico Scholtz like
5+ years ago. Wiring a dependency on parent directories directly is the
only implementation (that I know of) that has a prayer of accomplishing
the necessary (and yes, annoying) goal of improving the quality of  
*.rpm packages.


73 de Jeff

Re: [CVS] RPM: rpm/ CHANGES VENDOR rpm/lib/ depends.c

2008-10-28 Thread Jeff Johnson


On Oct 28, 2008, at 2:09 PM, devzero2000 wrote:

Could be better also to fullfill automatically /etc/rpm/sysinfo/ 
Dirname e Filelinkto, giving an hint to the user ? In this case  
there is the possibilty to catch this packaging error and to improve  
the quality of the system -- and the distro.




I did miss one item in the original question, permit me a direct reply.

My paraphrasing of what was requested is
Can rpmbuild detect orphan directories or dangling symlinks?

The RFE is perfectly sensible, based on a well-known principle
The earlier you detect an error, the easier it is to fix.

When producing *.rpm packages, the only earlier is upstream
in most cases. Fixing a problem upstream certainly removes
the need to do anything in RPM whatsoever.

The problem that is (so far) unsolved is that rpmbuild does not
have sufficient information to detect orphan directories or dangling
symlinks while building.

Packages are unit builds, and largely free of the distro context for
which they are being built.

So rpmbuild would either need a larger context (i.e. an everything
rpmdb for the distro which is intended to include the build), or a
narrower (and more restrictive) packaging policy would need to be  
attempted.


I tend to dislike policies implemented by tools that are  
insufficiently general.


But there are more restrictive policies like
	All package(s) in build set will satisfy parentdir  filelinkto  
dependencies.

that could be enforced by rpmbuild without additional context.

OTOH, if an rpmdb were maintained incrementally to reflect the
current target distro context, where it would be possible to check if  
__SOME__

package has the necessary parentdir/linkto dependency resolution, that
is more general (and less restrictive) a policy than what I just  
mentioned.


However, there is an additional cost associated maintaining an  
everything
rpmdb so that rpmbuild would be permitted a more relaxed (and more  
general)

build policy, with detction or madatory enforcement, simply restated as
	__SOME__ package(s) in a distro need to satisfy parentdir/filelinkto  
dependencies.


I can go either way, more than willing to do an implementation.

My sole interest is improving the quality of *.rpm packages. Package  
managers

should manage package contents, the policies above just force additional
items, parent directories  symlink end-points, into packages so that  
the

information can be managed just like all other package information.

hth

73 de Jeff

__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org