The bulk of this looks like it should go to sourcejuicer-discuss. I'll let
you re-ask your questions there. Picking out some of the other bits ...
On Thu, Mar 26, 2009 at 11:58:33AM +0000, Tomasz Kloczko wrote:
> For example I want to start working on few packages for submit to SJ but
> I can not start working on this because there is no package with
> pkgbuild tool in /rel or even /dev IPS repositories.
You could make a case for pkgbuild going into /dev. You could make a
better case for pkgbuild going into /contrib. Again, something for the
sourcejuicer (or pkgfactory?) folks.
> First: I know that traditional/"normal" Solaris package has listed
> in files list all directories .. but IMO it is bad habit.
> IMO if we want to start working on some new way of packaging we should drop
> this habit.
> Base directories hierarchy should be only in some core distribution package
> .. and nowhere else.
We're eventually going to do that, yes, but probably not until we start
producing pkg(5) packages without going through SVr4 first.
> Some comments and questions related to above example and OpenSolaris:
> - autoreconf does not work in OpenSolaris (there is no package which provides
> /usr/bin/aclocal .. simple autoreconf fails by lack this tool which should
> come with latest version automake package).
> Simple .. automake 1.10.x which comes with OpensSolaris is broken [1].
> Clarification: above my example uses autoreconf because %patch0 patches
> configure.ac file,
You should file a bug in solaris/utility/automake on bugs.opensolaris.org
(not defect). It looks like it would die trying to use "automake" as well.
Als note that a workaround is that you can set the environment variables
$ACLOCAL and $AUTOMAKE to override what autoreconf looks for.
> - %post and %postun rpm scripts should be replaced by some actions scripts in
> case OpenSiolaris.
> Q: do we have any actions script for update/regenerate on install/uninstall
> stage %{_infodir}/dir index file?
There's an ARC case for a service that will update GNU Info "dir" files --
PSARC/2007/375 -- but it's been in "waiting need spec" for almost two
years, which probably means that no one's had time to finalize the
specification.
> - what about language dependent files like gettext *.mo files in case
> OpenSolaris?
> (in above example files collected by "%find_lang %{name}" macro and
> inserted in
> %files list by "-f %{name}.lang" %files parameter).
> Q1: do we have any special language dependent attributes on IPS level
> package description level?
> Q2: What about %doc attribute?
We plan to have "facets" for locale-specific files and documentation that
would allow you to choose what locales you wanted installed on the system
and whether or not to install documentation, but the support isn't there
yet.
> - OpenSolaris install scrip still handles only one (first) directory and
> executing
> "istall -d /foo /bar" creates only first (/foo) directory:
The SVr4 install program is a crazy weird program. You should probably
just use GNU install, available as /usr/bin/ginstall or
/usr/gnu/bin/install, which will work like you expect.
> [1] I found another (IMO) bug in autoconf/automake package dependences:
>
> tkloc...@kloczek:~# pkg uninstall SUNWgnu-automake-19; pkg uninstall
> SUNWgnu-automake-110
> Creating Plan /pkg: Cannot remove
> 'pkg:/[email protected],5.11-0.109:20090305T192726Z' due to
> the following packages that depend on it:
> pkg:/[email protected],5.11-0.86:20081204T035913Z
> pkg:/[email protected],5.11-0.109:20090305T202740Z
>
> Why automake packages are required by gcc?
They're not. "gcc-dev" and "ss-dev" are "group packages" that are intended
to be "everything a typical developer needs". If all you want is the
compiler, you can install SUNWgcc or sunstudio. But most people are going
to want make and autoconf and bison and the other things that are part of
these group packages.
If you want to remove ss-dev or gcc-dev from your system, doing so won't
(currently; see bug 1728) remove anything else they brought in, so once you
do that, you can then remove the automake packages if you don't want them
any more.
> BTW1: what about build stage dependencies ? (Buildrequires and Buildconflicts
> rpm tags)
We expect to have a package per-consolidation that brings in all the
build-time dependencies for that consolidation. Note that because pkg(5)
does not have a build system built-in (like RPM does), then having specific
tags to support it is a project outside the scope of the core system.
That's not to say we won't support it, but it'll have to be layered on top.
There have been many discussions in the past on this list; I'll let you
read the archives rather than bringing all that up again.
> BTW2: why pkg does not accept multiple package names in install/uninstall
> parameters?
> Bug ? fracture ? or should I create RFE for this?
Multiple packages should be accepted for install and uninstall already.
However, if you try to uninstall multiple packages, you might run into bug
4068.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
