Re: Splitting in /usr/lib/<arch> and /usr/share
Thibaut Paumard <thibaut@debian.org> writes:
> Le 08/03/2014 14:02, Оlе Ѕtrеісhеr a écrit :
>> Hi,
>>
>> I am packaging some older software (eso-midas, [1]) that installs
>> everything into a common directory (f.e. /usr/lib/eso-midas/). However,
>> the FHS requires that this should be split between /usr/share/ and
>> /usr/lib/<arch>/. In the majority of cases, this could be done
>> automatically by recognizing the type with the "file" command: object
>> files, libs etc. go to /usr/lib/<arch>/eso-midas/, all text and data
>> files to /usr/share/eso-midas (with a link to
>> /usr/lib/<arch>/eso-midas).
>>
>> Is there already a little helper script that does this for me?
> Nice you are packaging MIDAS.
Let's see how far I come. BTW, Since I do not use it myself: Is it worth
to split it into core, applic, stdred, and contrib packages? Is there
any use for keeping the source?
> I don't know any such script, and I doubt it would do the right job
> anyway. Are the indep files generated?
Some of them are. The main "generation" is the setting of the MIDAS_HOME
variable then.
> What I would try is to compile the package on two distinct architectures
> (or more) and compare the result. That would work unless the build for
> these files is non-deterministic or includes timestamps or information
> on the build machine.
I was looking for an automated way. I would just do the following:
* put all files that are obviously system dependent to /usr/lib
* put all files that are obviously system independent to /usr/share
* Check all other files and put them to the right place
However, this is (as well as your proposal) manual work, and has to be
repeated with each release. Therefore I was hoping to have the majority
of files automatically put to the right place and deal only with the
ones where the automatic way fails.
> I guess you do realize that this split also implies putting the indep
> files in a separate arch:all package.
Yes. However, together with a source package (if needed), and a split
into components (see above), this easily multiplies into a total of 12
binary packages. I'd need some advice here.
Cheers
Ole
Reply to: