octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #45369] pkg build leads to duplication of PKG_


From: Julien Bect
Subject: [Octave-bug-tracker] [bug #45369] pkg build leads to duplication of PKG_ADD and PKG_DEL files
Date: Thu, 09 Jul 2015 07:47:00 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0

Follow-up Comment #24, bug #45369 (project octave):

Here is a new version of the approach proposed in Comment #8.

-----

1) No longer accept PKG_ADD/PKG_DEL files at the root of the package tarball.

1.1) Transition period: if there is a PKG_ADD/PKG_DEL file at the root of the
package and none in ./src (for source tarballs) or ./inst/$ARCH (for binary
tarballs), warn about deprecated package structure and move the files to the
arch-dependent directory. (Remark: currently, it seems assumed that packages
with a PKG_ADD/PKG_DEL file must have an arch-dependent directory. I would
change that and move the files to the arch-independent directory if there is
nio arch-dependent.)

1.2) Later: after the transition period, turn the warning into an error.

-----

2) Accept PKG_ADD/PKG_DEL files in ./inst, or in any subdirectory of ./inst.

2.1) Those files are copied at the corresponding location in the
arch-independent directory. This means that pkg must copy PKG_ADD/PKG_DEL
files (or all files ?) together with m-files. (I believe that the current
behaviour is to ignore non-m-files, but I couldn't find the place where this
happens in the code.)

2.2) When a package is loaded, only the top-level PKG_ADD file is executed,
when the directory is addpath-ed. The other ones are not executed
automatically. They will be executed, typically, when the top-level PKG_ADD
file adds the subdirectories to the path (if it does). And similarly for
PKG_DEL.

-----

3) Also, accept PKG_ADD/PKG_DEL files in ./src (for source packages) or in
./inst/ARCH-NAME (for binary packages). Those files are copied in the
arch-dependent directory.

3.1) Note that ./src and ./inst/ARCH-NAME should never exist simultaneously,
since the second one is created by pkg build, which removes src.

----

4) Keep accepting PKG_ADD/PKG_DEL directives (of course)

4.1) Note: I think that PKG_ADD/PKG_DEL directives should also be accepted in
subdirectories, for consistency. Currently they are ignored.

4.2) PKG_ADD/PKG_DEL directives located in m-files (in ./inst or
subdirectories of ./inst) must be removed (or disabled) from theses files
after having been processed. This will prevent them from being processed twice
in the case of "pkg build" followed by "pkg install". There is no such problem
with C++ source files, since the src directory is not included in the binary
tarball by "pkg build".

4.3) Note: 4.2 is slightly different from the solutions discussed in previous
comments. But this seems to be the lightest solution to implement, since "pkg
build" actually installs the package using the same install () subfunction as
"pkg install" and then creates a binary tarball using the repackage ()
subfunction.

-----

5) To make things perfectly clear for package developpers, specify in the
documentation in which order the two directories (on platforms where they are
separate) are addpath-ed/rmpath-ed at package load/unload time, and therefore
in which order the corresponding PKG_ADD/PKG_DEL files are executed.

-----

6) Process demos and test blocks from C++ source files and install them in the
arch-independent directory.

6.1) I haven't checked the solution proposed in bug reports #41298 and #41215,
but I assume this is what they do.

6.2) We must ensure that this plays well with the "pkg build" / "pkg install"
combo, i.e., that the corresponding files (*.tst or whatever) are properly
repackaged (copied from the arch-independent dir to ./inst in the binary
tarball, for instance) and then installed (i.e. copied back from ./inst to the
arch-independent directory).

-----

What do you think ?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45369>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]