[oi-dev] P5M dir action and other questions

[Jim Klimov]

12 апреля 2016 г. 7:11:38 CEST, bentahyr at chez.com пишет:
>Hi,
>
>I see that I don't have to put dir action in p5m so I was wondering
>when should I use it and when I shouldn't ?
>Should I assume that if a file action point to a directory that doesn't
>exist, IPS will create the dir ?
>
>I started to package gCompris but it is 267M tar.bz2, so it will be a
>big package (prototype directory is 355M). Is there any strategy or
>policy around separating progs from data, from regional data sets ?
>
>I started to package elinks unstable because the v0.11 doesn't work
>properly, it seems and I have the following issue.
>The archive file is elinks-current-0.13.tar.bz2 but once unpacked, the
>source directory is elinks-0.13-20160323/ (change the date every day).
>I tried a few tricks in the Makefile but none of them seems to be
>robust. What would be the proper strategy to tackle the fact that every
>download might lead to a changing source directory name ?
>
>Finally is there a way to have 2 packages offering the same binaries
>but you can't install both of them ? The example would be to have 2
>packages elinks and elinks-unstable packages both offering /bin/elinks
>but being unable to install both of them.
>
>Thanks  for answering all my questions again and again and....
>
>Best regards.
>Ben
>
>_______________________________________________
>oi-dev mailing list
>oi-dev at openindiana.org
>http://openindiana.org/mailman/listinfo/oi-dev

For directories - I think concensus du jour is to not deliver actions and attributes which the system can guess correctly - so common defaults are easier to revise "if what" in the futhre. This is not only directories that hold files in your manifest, but also owner=, group= and mode= tags with apparent values (e.g. executability for bins and *.so's). Conversely, if you have objects with non-default values (specific non-root/bin/sys ownership, suid bits, etc.) - then you list them.

I am not sure how to go about directories for non-root owned program data, such as logs or database files - whether to deliver them as P5M actions or by some first-run SMF service: cleaning up non-empty p5m-delivered dirs (upon uninstall) is problematic. I looked for inspiration in database packaging but did not come up with a good and/or generic answer.

As for splitting into sub-packages - case-by-case. A project often delivers libraries a third-party component can link against at run-time (we only deliver .so and .pc files, not .a or .la unless very well argued for), headers and similar resources for developers and packagers needed at compile-time, perhaps large demo setups for developers to be inspired by, localized pdf'ized+html'ized and otherwise redundant documentation, CLI tools and services, etc. Depending on amount of objects, logical boundaries and/or size, these can warrant separate packages and perhaps an umbrella package that lists these children with specific IPS and BUILD version vars and a chosen type of dependency (typically requires or optional, and iirc there is exclude for your other question; see e.g. Oracle IPS web docs for details). Speaking of sizem remember of dependencies, e.g. this couple of tools or bindings in a C project would pull Java, X11 or somesuch optional monster - do we require that bit to be in
core? If not, package them separately and pkgdepend will usually guess what they need.

Finally, for variant packages seek ideas in database or email services. Often they deliver unique object pathnames (dedicated subdirs or just unrelated projects with no conflict) and use mediated links so a user can choose what he wants to see as /usr/lib/sendmail or /usr/bin/java or /usr/bin/postgres...

At least, these are showels I stepped on in the recent months ;)

HTH,
Jim Klimov
--
Typos courtesy of K-9 Mail on my Samsung Android