packaging the file system for Solaris and rpm 4.4.9

[David Halik]

Tim... and of course anyone else with some advice,

There's another question I wanted to ask your opinion on after seeing
all the work you've done with rpm on Solaris. We're in the process of
migrating from 4.1 to the latest stable, a long overdue project. Outside
of actually building it (which seems to work fine except for the above
issue) there's one big hurdle to get over. I found out with the first
test install how strict rpm now is with its file list, deps, and
provides. The basic file system, i.e. /usr, /var, and so forth, is now
considered a dependency when installing. With earlier versions we've
never had this issue and rpm would be happy to use the existing core
file system as long as the directories already existed. Since the core
file system is not owned by any package, rpm refuses to install anything
installed in, for example, /usr/local, or plan /usr for that matter. I'm
fine with this, but obviously we need a way of reliably convincing rpm
that the necessary Solaris system is in fact there. One way we've found
around this so far is to make a virtual file system package that does
nothing more than Provides: /usr /usr/local, etc.

As long as all the core paths are provided and the package is the first
installed, all seems to be well, but obviously this could potentially be
a dangerous hack, not to mention constantly keeping it accurate and
including the multitude of locale's and so on. Another possibility is
actually hacking the Provides to include whatever is necessary, but I'd
just assume make an rpm than do that.

Any advice on this? I'm figuring you must have run into something
similar if you're bolting rpm on top of Solaris like we are. We'd love
to hear your opinion.

Thanks again,
-Dave

[Tim Mooney]

I found out with the first test install how strict rpm now
is with its file list, deps, and provides. The basic file system, i.e. /usr,
/var, and so forth, is now considered a dependency when installing. With
earlier versions we've never had this issue and rpm would be happy to use the
existing core file system as long as the directories already existed. Since
the core file system is not owned by any package, rpm refuses to install
anything installed in, for example, /usr/local, or plan /usr for that matter.
I'm fine with this, but obviously we need a way of reliably convincing rpm
that the necessary Solaris system is in fact there. One way we've found around
this so far is to make a virtual file system package that does nothing more
than Provides: /usr /usr/local, etc.

I think Jeff may have posted a way you can actually turn that off, but I
wouldn't go that route.

You have a couple options.

- use packages that provide the directory in question, as you're currently
doing.

- just add the directories to /etc/rpm/sysinfo.

I would recommend the first method, as it feels more clean to me. The
second one will do in a pinch, to tide you over until you're ready to
install revision N+1 of your filesystem package that includes the
directory you just realized you need. ;-)

Note that the vpkg-provides that comes with RPM that aids in building
virtual packages could be extended to also Provide: directories, or a
simple script could autogenerate the list of directories that you might
want to provide in a virtual package.

The good news is that if you restrict where local packages managed by RPM
can install files, you only need a few directories in your "filesystem"
virtual package. You just need to update your spec files for you local
packages to make sure that they claim any directories that are theirs and
theirs alone. For example, in my spec file "gettext", I have the %install
section pre-create all the locales I've encountered in any package so
far, so that the gettext package can claim all those directories:

#
# TVM: so that this RPM claims as many of the language directories as
# possible, create as many as we know about now:
#
( cd $RPM_BUILD_ROOT%{LOCALE_DIR}/.. \
&& for d in af am ar as az be ***@latin bg bn bn_IN bs ca cs cy da de dz \
el ***@boldquot ***@quot en_CA en_GB eo es et eu \
fa fi fr ga gl gu he hi hr hu id is it ja ka kn ko ku \
li lt lv mg mi mk ml mn mr ms nb ne nl nn no oc or \
pa pl pt pt_BR ro ru rw si sk sl sq sr ***@ije ***@Latn sv \
ta te th tk tr tt ug uk vi wa xh yi zh_CN zh_HK zh_TW ; \
do \
test -d locale/$d/LC_MESSAGES || %__mkdir_p locale/$d/LC_MESSAGES ; \
done ; )


Then my %files section claims them:

%dir %{LOCALE_DIR}
%{LOCALE_DIR}/locale.alias
%dir %{LOCALE_DIR}/??
%dir %{LOCALE_DIR}/*_*
%dir %{LOCALE_DIR}/*@*
%dir %{LOCALE_DIR}/*/LC_MESSAGES


Tim

[Jeff Johnson]

Post by David Halik

I found out with the first test install how strict rpm now
is with its file list, deps, and provides. The basic file system, i.e.

/usr,

/var, and so forth, is now considered a dependency when installing. With
earlier versions we've never had this issue and rpm would be happy to

use the

existing core file system as long as the directories already existed.

Since

the core file system is not owned by any package, rpm refuses to install
anything installed in, for example, /usr/local, or plan /usr for that

matter.

I'm fine with this, but obviously we need a way of reliably convincing

rpm

that the necessary Solaris system is in fact there. One way we've found

around

this so far is to make a virtual file system package that does nothing

more

than Provides: /usr /usr/local, etc.

I think Jeff may have posted a way you can actually turn that off, but I
wouldn't go that route.

Adding --noorphandirs (or --nolinktos for the other new implicit dependency)
wrapping rpm with a popt alias (or even shell) is always available.

There are ongoing efforts to make the behavior configurable in
rpm-4_5 for "everywhere compatible" behavior. On Solaris you
can always patch to disable the 2 bits and rebuild. I'd send you
the patch but there are too many flip-flop variant diddles over
the last year. All I can say is that its easy to disable 2 bits ...


You have a couple options.

Post by David Halik
- use packages that provide the directory in question, as you're currently
doing.
- just add the directories to /etc/rpm/sysinfo.
I would recommend the first method, as it feels more clean to me. The
second one will do in a pinch, to tide you over until you're ready to
install revision N+1 of your filesystem package that includes the
directory you just realized you need. ;-)

Adding a directory skeleton package like "filesystem" on
linux distros is likely the soundest approach. Make sure
you pay attention to owner/group/mode on directories,
but after a "filesystem" package exists, its very low maintenance.

Most of the unowned directories are i18n peculier, either locales
or man pages (see Tim's perfectly sensible alternative solution below).

Adding a "filesystem-i18n" directory skeleton package isolates
the maintenance (what I would likely do).

rpm packaging deals best with static unchanging content.

73 de Jeff

Note that the vpkg-provides that comes with RPM that aids in building

Post by David Halik
virtual packages could be extended to also Provide: directories, or a
simple script could autogenerate the list of directories that you might
want to provide in a virtual package.
The good news is that if you restrict where local packages managed by RPM
can install files, you only need a few directories in your "filesystem"
virtual package. You just need to update your spec files for you local
packages to make sure that they claim any directories that are theirs and
theirs alone. For example, in my spec file "gettext", I have the %install
section pre-create all the locales I've encountered in any package so
#
# TVM: so that this RPM claims as many of the language directories as
#
( cd $RPM_BUILD_ROOT%{LOCALE_DIR}/.. \
fa fi fr ga gl gu he hi hr hu id is it ja ka kn ko ku \
li lt lv mg mi mk ml mn mr ms nb ne nl nn no oc or \
ta te th tk tr tt ug uk vi wa xh yi zh_CN zh_HK zh_TW ; \
do \
test -d locale/$d/LC_MESSAGES || %__mkdir_p locale/$d/LC_MESSAGES ; \
done ; )
%dir %{LOCALE_DIR}
%{LOCALE_DIR}/locale.alias
%dir %{LOCALE_DIR}/??
%dir %{LOCALE_DIR}/*_*
%dir %{LOCALE_DIR}/*/LC_MESSAGES
Tim
--
Information Technology Services [phone] (Voice)
Room 242-J6, IACC Building [phone] (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[David Halik]

Post by Jeff Johnson
Adding --noorphandirs (or --nolinktos for the other new implicit dependency)
wrapping rpm with a popt alias (or even shell) is always available.

I'm guessing you meant --noparentdirs? I've been using it for testing
purposes and works nicely in a pinch.

Post by Jeff Johnson
There are ongoing efforts to make the behavior configurable in
rpm-4_5 for "everywhere compatible" behavior. On Solaris you
can always patch to disable the 2 bits and rebuild. I'd send you
the patch but there are too many flip-flop variant diddles over
the last year. All I can say is that its easy to disable 2 bits ...

That would be great to have it configurable in 4.5. For now I think
we're just going to have a skeleton system provided by our current
vpkgs. They need some tweaking for this, but I'll only have to do it
once, and this method sounds like the best way to go at it.

Thanks,
-Dave