paul varner

(There are several things in here and what I'm looking for is discussion
and education)

I've been playing with my system configuration lately so that I can gain
a deeper understanding of the features of the portage system.

I'm currently using portage-2.0.51_pre13, so I'm assuming this version
and higher for the purposes of thsi discussion.

One of my goals is to have a minimal world file that only contains the
applications that I want installed on a system and when combined with a
specific profile and /etc/portage/virtuals - (to set things where I
don't like the defaults i.e. postfix for virtual/mta) would allow me to
rebuild / maintain a fairly clean system.

During all of this I removed syslog-ng from my world file which led to
the following bug report <http://bugs.gentoo.org/show_bug.cgi?id=57787>
about vixie-cron not having a runtime dependency on virtual/logger.

Anyhow, this led me to start thinking about the system profiles.
Neither cron or a system logger are in the system profiles, yet having
many years of Unix/Linux administration experience, they are a fairly
vital part of a "normal" Unix/Linux system.

My conjecture for why they are not in the system profile is because they
are not required to operate a system and since Gentoo is about choice we
are not going to dictate a specific version of cron or a specific system
logger.

This is where stackable profiles and virtuals come in. To me these
applications are part of a normal default Linux installation (be it a
server or workstation) and should be considered part of the system
software and I see a couple of ways to approach this.

The first and simplest is that virtual/logger and virtual/cron be added
to the system profile. If this were to happen, the defaults (dcron &
sysklogd for default-x86 profiles) would be installed during the
installation process.

If I don't like those defaults, I could unmerge the defaults and emerge
the software I did prefer after the installation. Kind of blech type of
solution to me. The other alternative is to setup /etc/portage/virtuals
to override the defaults prior to installation.

The second way based upon what I've read is to use a stackable profile.
Unfortunately, I can't find any implementation do***entation on them, so
I don't know if portage supports them and if so, how to use them. It
seems to me though that with a stackable profile, I could add those
pieces of software that I consider to be part of the system but are not
required to run the system to *my* system profile. This allows Gentoo
to keep the default profiles small with only the required software, and
allows me the choice to expand upon what is provided by Gentoo.

Finally dependencies, since I have been writing and tinkering with
ebuilds at what point do you stop adding dependencies to the ebuild. To
be **** about it would be to add everything back to glibc. That is
obviously not the case and the assumption that I've been making is that
if it isn't in the system profile and it is required to build/run the
package then it should be listed as a dependency. That was my reasoning
for filing the above bug. As a system logger isn't required by the
system profile and vixie-cron requires one to run, it should be listed
as a runtime dependency. In this case, I was told politely that I was
nuts since "There's no reason for vixie-cron to rdepend on
virtual/logger". I obviously disagree with that assessment, which is
why I'm asking the question. (Side note: I don't have a lot of
heartburn with the bug report being rejected, although I do feel it is a
valid bug or I wouldn't have submitted it. My opinion is that if it is
not going to be addressed, the resolution should be WONTFIX instead of
INVALID)

If you've read this far, thanks for reading and I appreciate any
thoughts, ideas, etc on all of this.

Regards,
Paul


--
gentoo-dev@gentoo.org mailing list

seemant kulleen

Hi Paul,

Others can give you a better response -- but as for the virtual/logger
and virtual/cron in system profiles, I think that would mess up the
livecd and install stages, because they would then get bloated up.

As far as cascading profiles are concerned -- we don't have any way to
add custom stuffs to the profiles (yet?). It might be on the roadmap
for some future date, though. The immediate goal for cascading profiles
was really to de-bloat /usr/portage/profiles. I'd suggest filing a bug
to dev-portage@gentoo for the custom support though.
--
"Check out the hook while my DJ revolves it"

Seemant Kulleen
http://dev.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/svY7aJl2DRYeA4RAlDvAKDDGlwMOJz0m0010lIujZ1rZex+xgC gtdy6
vIV0SXxREwKpiOfVviHLzmE=
=DQ7f
-----END PGP SIGNATURE-----

chris gianelloni

vixie-cron can run fine without any logger at all. I have actually
configured such a system, simply when playing around. What happens is
any messages are dumped to the console, which isn't very good, but
proves that there is no hard requirement for a logger.

--
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/uWekT4lNIS36YERAq//AJ9U5L1hxdRLKodiDhmKp+9x66wRkwCfZFmx
sjfXj/+Wtw5F1ICSgDfLK2Q=
=yhBr
-----END PGP SIGNATURE-----

paul varner

If that's the case then the ebuild shouldn't install a startup file into
/etc/init.d that has "need logger" in its depend section. It should be
changed to a "use logger".

Currently as installed by the ebuild, vixie-cron requires a system
logger to be installed to operate correctly.

--
My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo

--
gentoo-dev@gentoo.org mailing list

chris gianelloni

I agree. File a bug. You might want to check dcron and the others, too.

Then that is a bug in the ebuild and should be treated as such... =]

--
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBA/7P2kT4lNIS36YERApjOAJ9tBfP4nnzh+ya37LkFFBlHYwsRNQC ePsGZ
IYnQk25jQ2GsqdiLrrg4myI=
=AhhQ
-----END PGP SIGNATURE-----