11:38 a.m.
Hi,
I've been reading past posts and am starting to understand the goals of
the Fedora project much better. If I'm not mistaken, the primary goal
isn't to target a specific set of users (ie. desktop vs. server) or
platform (x86_64 vs. ppc, notebook vs. desktop), but to come up with a
distro that's easy to re-spin for people who DO want to customize Fedora
for a particular purpose.
If that's the case, would I be correct in assuming that Fedora would
prioritize increasing the modularity of its packages? That Fedora is
making it easier to add or remove while minimizing the affect it would
have on other packages?
For instance, if I desired to come up with a spin that doesn't have
Sendmail, why must I give up fetchmail, mutt or tor? Why is it that so
many packages can't stand alone without libvorbis? I know that some of
the packages NEED libvorbis, but for many, shouldn't it be optional and
something that isn't required to be compiled against (think dlopen(3)
instead of ld(1)) like gstreamer-plugins-* (which all seem to require
libvorbis)?
I guess I'm just stating a principle which should be a guiding one if
Fedora wants to come up with a system that's really flexible for people
who want to come up with their own spins. So currently, is it (a guiding
principle to make packages modular and depend less on others)?
Note that I'm not asking if this is to be a target, just if it's written
somewhere as something to keep in mind when packaging things. I
understand that Fedora is dealing with a huge system that's been around
for ages. Some people's complaints about Fedora being too bulky isn't
even Fedora's fault. They've just been dealing with a relic that it has
to modernize. Towards that goal, Fedora has done a lot and continues to
improve on it (next-gen init, boot-up process, etc.).
--
Richi Plana
11:57 a.m.
Richi Plana (myfedora(a)richip.dhs.org) said:
For instance, if I desired to come up with a spin that doesn't
have
Sendmail, why must I give up fetchmail, mutt or tor?
Because they *require* a MTA to deliver/send the mail, at least in their
default configurations
Why is it that so
many packages can't stand alone without libvorbis? I know that some of
the packages NEED libvorbis, but for many, shouldn't it be optional and
something that isn't required to be compiled against (think dlopen(3)
instead of ld(1)) like gstreamer-plugins-* (which all seem to require
libvorbis)?
dlopen will cause you to break at runtime instead of buildtime if
ABI changes - that's not good.
Bill
12:22 p.m.
On Tue, 2007-09-04 at 12:57 -0400, Bill Nottingham wrote:
Richi Plana (myfedora(a)richip.dhs.org) said:
> For instance, if I desired to come up with a spin that doesn't have
> Sendmail, why must I give up fetchmail, mutt or tor?
Because they *require* a MTA to deliver/send the mail, at least in their
default configurations
Well, I figured that they are required because of their default
configurations. But would Fedora be interested in changing it if
modularity were indeed the higher goal?
Besides, you said it requires an MTA. Would an effort to add the ability
to detect the availability of /sbin/sendmail in the above-mentioned
packages and use it if available or speak SMTP over port 25 if not be
desirable? Packages like evolution and thunderbird do that and therefore
don't "Require: sendmail".
> Why is it that so
> many packages can't stand alone without libvorbis? I know that some of
> the packages NEED libvorbis, but for many, shouldn't it be optional and
> something that isn't required to be compiled against (think dlopen(3)
> instead of ld(1)) like gstreamer-plugins-* (which all seem to require
> libvorbis)?
dlopen will cause you to break at runtime instead of buildtime if
ABI changes - that's not good.
Isn't that what escalating the version number to a higher layer (ie. RPM
and yum) is all about? Currently, a break in ABI would result in an
executable loader error. It would just be a conscious effort to move
catching it from there to package management. If dlsym(3) were more
verbose, it might even expose changes API/ABI changes.
At any rate, other packages do it. Some multimedia apps do. Apache httpd
does it. For apache, module (or plugin or whatever they call it)
packages can be added or removed without affecting the system much.
It's a huge effort, I know, but all I'm asking is if it's not in the
guiding principles list that Fedora has. It would certainly make
packagers and spinners very happy.
--
Richi Plana
12:55 p.m.
Richi Plana (myfedora(a)richip.dhs.org) said:
On Tue, 2007-09-04 at 12:57 -0400, Bill Nottingham wrote:
> Richi Plana (myfedora(a)richip.dhs.org) said:
> > For instance, if I desired to come up with a spin that doesn't have
> > Sendmail, why must I give up fetchmail, mutt or tor?
>
> Because they *require* a MTA to deliver/send the mail, at least in their
> default configurations
Well, I figured that they are required because of their default
configurations. But would Fedora be interested in changing it if
modularity were indeed the higher goal?
Besides, you said it requires an MTA. Would an effort to add the ability
to detect the availability of /sbin/sendmail in the above-mentioned
packages and use it if available or speak SMTP over port 25 if not be
desirable? Packages like evolution and thunderbird do that and therefore
don't "Require: sendmail".
It's somehow better to have each package require its own separate
configuration than to use a central package that only takes 2MB? I'm
not saying you can't do it, but:
- every mutt user would have to set up their own muttrc with smtp server information
- every fetchmail user would have to change their invocation
- and so on, for each package as needed
> dlopen will cause you to break at runtime instead of buildtime
if
> ABI changes - that's not good.
Isn't that what escalating the version number to a higher layer (ie. RPM
and yum) is all about?
Sure, but then you're still breaking at runtime instead of build/install
time.
Bill
2:34 p.m.
On Tue, 2007-09-04 at 13:55 -0400, Bill Nottingham wrote:
It's somehow better to have each package require its own
separate
configuration than to use a central package that only takes 2MB? I'm
not saying you can't do it, but:
- every mutt user would have to set up their own muttrc with smtp server information
- every fetchmail user would have to change their invocation
- and so on, for each package as needed
I would say services directory or service discovery. But I digress.
BTW, evolution and thunderbird users set up their own outgoing mail
configuration. Personally it would be nicer if these services could be
discovered or configured by an administrator globally or per user, but
if the usage of a program like /sbin/sendmail must be hardcoded, then at
the very least have some kind of smart fallback.
> > dlopen will cause you to break at runtime instead of
buildtime if
> > ABI changes - that's not good.
>
> Isn't that what escalating the version number to a higher layer (ie. RPM
> and yum) is all about?
Sure, but then you're still breaking at runtime instead of build/install
time.
You probably would, but that would be limited with correct versioning
and package management. It wouldn't be any worse than Apache httpd
modules or gstreamer-plugins (the plugins themselves and not the
libraries they link against. Fortunately, it's pretty stable).
--
Richi Plana
9:19 a.m.
On Tue, Sep 04, 2007 at 11:22:28 -0600,
Richi Plana <myfedora(a)richip.dhs.org> wrote:
Besides, you said it requires an MTA. Would an effort to add the ability
to detect the availability of /sbin/sendmail in the above-mentioned
packages and use it if available or speak SMTP over port 25 if not be
desirable? Packages like evolution and thunderbird do that and therefore
don't "Require: sendmail".
Mutt isn't going to be able to use smtp. You really do want something local
to store messages in case there is a temporary problem in sending the mail
out. However, you could conceivably use mutt just to read email from a remote
imap server. That is probably not a likely use case though.
5:26 p.m.
Bruno Wolff III wrote:
> Besides, you said it requires an MTA. Would an effort to add the
> ability to detect the availability of /sbin/sendmail in the
> above-mentioned packages and use it if available or speak SMTP over
> port 25 if not be desirable? Packages like evolution and
> thunderbird do that and therefore don't "Require: sendmail".
Mutt isn't going to be able to use smtp.
As of 1.5.15 the world turned inside out and upside down and mutt
grew support for SMTP:
http://dev.mutt.org/trac/browser/ChangeLog#L1183
(The temperature in Hades may have even dropped by a few degrees, but
that's not confirmed. :)
You really do want something local to store messages in case there
is a temporary problem in sending the mail out. However, you could
conceivably use mutt just to read email from a remote imap server.
That is probably not a likely use case though.
Are there a lot of mutt users who aren't capable of doing the needed
configuration to match their setup? It seems like one package that
could survive without a "hold the users hand" approach to the possible
things it might depend on. ;-)
As of cvs rev 1.47, mutt.spec no longer requires sendmail. See:
http://cvs.fedora.redhat.com/viewcvs/devel/mutt/mutt.spec?r1=1.46&r2=...
and
https://bugzilla.redhat.com/show_bug.cgi?id=226167
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sex can be messy, but only if it's done right.
-- Groucho Marx
7:54 a.m.
On Wed, Sep 05, 2007 at 18:26:17 -0400,
Todd Zullinger <tmz(a)pobox.com> wrote:
As of 1.5.15 the world turned inside out and upside down and mutt
grew support for SMTP:
http://dev.mutt.org/trac/browser/ChangeLog#L1183
(The temperature in Hades may have even dropped by a few degrees, but
that's not confirmed. :)
That news is a shocker. A long time ago, I used to follow the dev list and
people seemed pretty adamant about it. (For what I think are good reasons.)
Are there a lot of mutt users who aren't capable of doing the
needed
configuration to match their setup? It seems like one package that
could survive without a "hold the users hand" approach to the possible
things it might depend on. ;-)
Where I work we have one or two. Professors who used command line from
way back, but just knew enough about that to get their stuff done. Now
they are reluctant to change.
12:35 p.m.
Bruno Wolff III wrote:
On Wed, Sep 05, 2007 at 18:26:17 -0400, Todd Zullinger
<tmz(a)pobox.com> wrote:
>
> As of 1.5.15 the world turned inside out and upside down and mutt
> grew support for SMTP:
[...]
That news is a shocker. A long time ago, I used to follow the dev
list and people seemed pretty adamant about it. (For what I think
are good reasons.)
Yeah, I figured that the change would be a surprise to some long time
mutt users.
> Are there a lot of mutt users who aren't capable of doing
the
> needed configuration to match their setup? It seems like one
> package that could survive without a "hold the users hand" approach
> to the possible things it might depend on. ;-)
Where I work we have one or two. Professors who used command line
from way back, but just knew enough about that to get their stuff
done. Now they are reluctant to change.
FWIW, I think that the smtp support will make it easier for users like
those professors to configure mutt. Most folks are acustomed to
plugging in the info on where to send as well as where to receive mail
in their MUA's. It seems scads simpler to set an smtp url than to
setup sendmail.
Anyway, now you've got a heads up on the change so if you're the guy
that'll be helping out the professors you'll know what's coming. ;-)
(Thanks to Miroslav Lichvar for updating the mutt rpm, BTW.)
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anarchism is founded on the observation that since few men are wise
enough to rule themselves, even fewer are wise enough to rule others.
-- Edward Abbey
12:54 p.m.
Le mardi 04 septembre 2007 à 12:57 -0400, Bill Nottingham a écrit :
Richi Plana (myfedora(a)richip.dhs.org) said:
> For instance, if I desired to come up with a spin that doesn't have
> Sendmail, why must I give up fetchmail, mutt or tor?
Because they *require* a MTA to deliver/send the mail, at least in their
default configurations
And BTW there's no need for this MTA to be sendmail
[nim@rousalka ~]$ rpm -q fetchmail
fetchmail-6.3.8-2.fc8.x86_64
[nim@rousalka ~]$ rpm -q sendmail
package sendmail is not installed
--
Nicolas Mailhot
1:04 p.m.
On 9/4/07, Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
And BTW there's no need for this MTA to be sendmail
to be
a little more explicit
repoquery --whatprovides smtpdaemon
sendmail
postfix
exim
ssmtp
all of those packages provide the necessary virtual provides that
fetchmail is asking to be filled. So in reality.. this particular
example is a non-problem. Any re-spinner has the option of using any
package that provides smtpdaemon... modularity via the virtual
provides.
repoquery tells me that the only things that explicitly need sendmail
are milter related.
-jef
3:31 p.m.
On 09/04/2007 12:57 PM, Bill Nottingham wrote:
Richi Plana (myfedora(a)richip.dhs.org) said:
> For instance, if I desired to come up with a spin that doesn't have
> Sendmail, why must I give up fetchmail, mutt or tor?
Because they *require* a MTA to deliver/send the mail, at least in their
default configurations
Seems to be the perfect case for a "Suggests" tag.
dpkg/apt has had it for a long time and I find it
very benefical.
It would also solve things such as mkinitrd claming a
hard dependency on lvm and dmraid for installation
ordering purposes.
Now that RPM is under active development again,
would such a new feature be possible?
--
// Bernardo Innocenti
\X/ http://www.codewiz.org/
10:58 a.m.
On 04/09/07, Bill Nottingham <notting(a)redhat.com> wrote:
> Why is it that so
> many packages can't stand alone without libvorbis? I know that some of
> the packages NEED libvorbis, but for many, shouldn't it be optional and
> something that isn't required to be compiled against (think dlopen(3)
> instead of ld(1)) like gstreamer-plugins-* (which all seem to require
> libvorbis)?
dlopen will cause you to break at runtime instead of buildtime if
ABI changes - that's not good.
Eh? You have a plugin that's linked to libvorbis, and then load *that*
at runtime; and you can rebuild the plugin independently of the main
application if the libvorbis API or ABI change. The point is to make
the need for (libvorbis is probably not the best example) the plugin
optional. The plugin has all the right dependencies so it depends on
the correct soname etc etc.
There is a good use case, and that was mentioned further down: pulling
in all the gstreamer-plugins packages gets me a shedload of
dependencies for various sound + video libraries that I never, ever
use, and that in combination with all the work-related stuff I have on
my machine here pushed me over the limit for prelinking everything
(prelink -av reported being unable to find an address slot for
something). Before everyone chimes in with "use -m" ... that kinda
makes prelinking pointless when a lot of libs are plugins that are
loaded dynamically, because prelink can't tell when they're used in
the same application based on the dependencies between the binaries
and libraries ...
11:23 a.m.
Bill Nottingham wrote:
Richi Plana (myfedora(a)richip.dhs.org) said:
> For instance, if I desired to come up with a spin that doesn't have
> Sendmail, why must I give up fetchmail, mutt or tor?
Because they *require* a MTA to deliver/send the mail, at least in their
default configurations
> Why is it that so
> many packages can't stand alone without libvorbis? I know that some of
> the packages NEED libvorbis, but for many, shouldn't it be optional and
> something that isn't required to be compiled against (think dlopen(3)
> instead of ld(1)) like gstreamer-plugins-* (which all seem to require
> libvorbis)?
dlopen will cause you to break at runtime instead of buildtime if
ABI changes - that's not good.
You should expect things to break when you change an interface - pretty
much by definition. If it hurts, don't do it.
--
Les Mikesell
lesmikesell(a)gmail.com
2:17 p.m.
Les Mikesell (lesmikesell(a)gmail.com) said:
> dlopen will cause you to break at runtime instead of buildtime
if
> ABI changes - that's not good.
You should expect things to break when you change an interface - pretty
much by definition. If it hurts, don't do it.
I was discussing a case where instead of linking against libvorbis, you
dlopen() it - that's the sort of thing which is really much better to
catch at buildtime. If you're dlopening the plugin that is itself linked
against libvorbis (or whatever), that's better.
Bill
3:06 p.m.
Bill Nottingham wrote:
Les Mikesell (lesmikesell(a)gmail.com) said:
>> dlopen will cause you to break at runtime instead of buildtime if
>> ABI changes - that's not good.
> You should expect things to break when you change an interface - pretty
> much by definition. If it hurts, don't do it.
I was discussing a case where instead of linking against libvorbis, you
dlopen() it - that's the sort of thing which is really much better to
catch at buildtime. If you're dlopening the plugin that is itself linked
against libvorbis (or whatever), that's better.
Won't anything using a shared library break if you replace that library
with one that does not follow the same interface definition whether it's
dlopen()ed or not? That's kind of the whole concept of interfaces -
they aren't supposed to change. If you write a new one, call it
something else.
--
Les Mikesell
lesmikesell(a)gmail.com
3:24 p.m.
Les Mikesell (lesmikesell(a)gmail.com) said:
> I was discussing a case where instead of linking against
libvorbis, you
> dlopen() it - that's the sort of thing which is really much better to
> catch at buildtime. If you're dlopening the plugin that is itself linked
> against libvorbis (or whatever), that's better.
Won't anything using a shared library break if you replace that library
with one that does not follow the same interface definition whether it's
dlopen()ed or not? That's kind of the whole concept of interfaces - they
aren't supposed to change. If you write a new one, call it something else.
Sure. But DT_NEEDED is tracked at the package level and can be
easily caught.
Bill
4:59 p.m.
Bill Nottingham wrote:
>> I was discussing a case where instead of linking against
libvorbis, you
>> dlopen() it - that's the sort of thing which is really much better to
>> catch at buildtime. If you're dlopening the plugin that is itself linked
>> against libvorbis (or whatever), that's better.
> Won't anything using a shared library break if you replace that library
> with one that does not follow the same interface definition whether it's
> dlopen()ed or not? That's kind of the whole concept of interfaces - they
> aren't supposed to change. If you write a new one, call it something else.
Sure. But DT_NEEDED is tracked at the package level and can be
easily caught.
Back to the beginning with this argument: if you are only planning to
dlopen() libvorbis in the presence of ogg files there's no particular
reason to expect it to be necessary at all, let alone a particular
version of it.
--
Les Mikesell
lesmikesell(a)gmail.com
7:29 p.m.
On Wed, 2007-09-05 at 16:59 -0500, Les Mikesell wrote:
Back to the beginning with this argument: if you are only planning to
dlopen() libvorbis in the presence of ogg files there's no particular
reason to expect it to be necessary at all, let alone a particular
version of it.
In the course of the discussion, certain information got blurred.
First of all, the idea was that for optional modules in certain
packages, it's desirable from a packaging perspective for the modules to
be separable from the main package (as in the case of apache httpd, php,
perl and gstreamer-plugins). Only if a library is optional and already
supports separationg from the main package. If it's required (no point
for having an Ogg vorbis player be separated from the vorbis library,
right?), then that's fine. If it's optional but the software isn't
written so that the optional module can be easily separated, then that
should first be taken up with the software developer ... or fork.
In the cases where the modules are optional and separable (because
they're supported by the language ... Perl, python and java modules are
separable by nature. C modules can be separable if they're dlopen(3)'d
as opposed to ld(1)), I'm hoping that the packagers take advantage of
this and package them separately (which is already done in a lot of
packages).
A couple of places where it COULD be done are a) gstreamer-plugins and
b) kernel modules.
I won't even go into kernel modules as even now there's a push to even
make it even more monolitically packaged. gstreamer-plugins COULD be
separated. They're only packaged as gstreamer-plugins-(base|good|bad|
ugly) because that's the way the developers packaged them. Technically,
a gstreamer-plugin-good.src.rpm could generate gstreamer-plugin-vorbis,
gstreamer-plugin-<whatever> and could all be pulled in by the virtual
gstreamer-plugin-package-good. As I was contemplating on actually doing
this, it occurred to me that I don't know how to do optional packaging
in RPM spec files based on the existence of the lib*.so files. (no
support in rpmbuild that I'm aware of, but I'm no expert.)
Anyway, as the original poster who brought up this thread, I'm not even
targetting specific packages but was wondering more about philosophy. If
it's written down somewhere that Fedora developers should keep an eye
out for making packages Modular so that distro-spinners have more
flexibility, then perhaps that would help devs down the line.
That's all.
--
Richi Plana
5:59 a.m.
On 05/09/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Back to the beginning with this argument: if you are only planning
to
dlopen() libvorbis in the presence of ogg files there's no particular
reason to expect it to be necessary at all, let alone a particular
version of it.
You have a plugin module for the application that is dlopen()'d by the
application itself. The plugin is linked, normally, against libvorbis
(or whatever). Then the build of the plugin will fail if the interface
changes. The interface of the plugin is under the control of the
application developer, and you can avoid breaking that at runtime by
e.g. versioning the directory path the plugins are stored in, or
something ...
3:27 p.m.
On Wed, 2007-09-05 at 15:06 -0500, Les Mikesell wrote:
Bill Nottingham wrote:
> Les Mikesell (lesmikesell(a)gmail.com) said:
>>> dlopen will cause you to break at runtime instead of buildtime if
>>> ABI changes - that's not good.
>> You should expect things to break when you change an interface - pretty
>> much by definition. If it hurts, don't do it.
>
> I was discussing a case where instead of linking against libvorbis, you
> dlopen() it - that's the sort of thing which is really much better to
> catch at buildtime. If you're dlopening the plugin that is itself linked
> against libvorbis (or whatever), that's better.
Won't anything using a shared library break if you replace that library
with one that does not follow the same interface definition whether it's
dlopen()ed or not? That's kind of the whole concept of interfaces -
they aren't supposed to change. If you write a new one, call it
something else.
That's what I meant when I said that catching interface changes like
that should be escalated to a higher layer: the version. It won't get
caught during loading of the executable (primarily because it's not
linked against it), but it's like any software you develop. You can put
error-checks at the lowest level function call and be assured of
catching everything, or putting them at a higher level making sure that
all entrances are checked. Coneptually, you could make changes to the
library that doesn't change the ABI but changes the semantics of the
function calls totally breaking the software that uses it but isn't
caught during linking (far-fetched though it may be).
The primary benefit to doing it this way (and a main concern of
distro-makers) is, of course, that packages don't need to hard-Require
optional modules (assuming they're optional to begin with). Other issues
aren't as interesting to distribution-makers and one could spend weeks
discussing the merits of doing it one way or another. Personally I've
written software that does both and I'm not convinced one is always
better over the other from a software developer's standpoint. Such isn't
the case for distro-makers.
--
Richi Plana
12:57 p.m.
On 9/4/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
gstreamer-plugins-*
Can you give me a plausibly rational usage
case where it is in the
best interest of the targeted usage group of any gstreamer based
application to not have ogg vorbis playback capability rolled into the
set of plugins? I can't.
Taking things to the extreme of ultimate modularity is a fallacy.
Making components modular has tradeoffs in terms of usability and the
discussion to increase modularity needs to have a usage case point of
view in mind.
-jef
2:08 p.m.
On Tue, 2007-09-04 at 09:57 -0800, Jeff Spaleta wrote:
On 9/4/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
> gstreamer-plugins-*
Can you give me a plausibly rational usage case where it is in the
best interest of the targeted usage group of any gstreamer based
application to not have ogg vorbis playback capability rolled into the
set of plugins? I can't.
The choice of libvorbis really was just to illustrate how something
that's optional in the usage sense isn't optional in the packaging
sense. I certainly can't come up with a use case where it won't be in
the best interest of the targeted userbase to have. Truth be told, the
gstreamer plugins system is exactly about modularity. It's the packaging
of the plugins into -good, -bad, -ugly that breaks the modularity in the
packaging sense. If I was a "modularity" zealot, I'd argue for having
gstreamer-plugins-ogg-vorbis packages, etc., but I'm not. Read below.
Taking things to the extreme of ultimate modularity is a fallacy.
Making components modular has tradeoffs in terms of usability and the
discussion to increase modularity needs to have a usage case point of
view in mind.
_I_ don't believe in ultimate or absolute anything. That's not what I
was looking for. In fact, I would even go so far as to say that there
should only be modularization when there's an existing need or even a
predicted, likely need. The whole point to my bringing up the topic of
keeping an eye on modularization was to solve a couple of problems that
some people have.
First, a couple of users are clamoring for lighter distributions.
Services which aren't needed shouldn't be installed. Some people asked
why certain services like sendmail needed to be installed. Somebody
replied by saying a respin could be done, so I just checked if it was
indeed possible by doing a "yum remove sendmail" and that's when I
discovered that mutt and tor needed them when they should be optional.
Of course, as it turns out, it's not sendmail that they require
specifically but smtpdaemon. So I was in error with that example as the
system DOES show a good deal of modularity via the virtual provides.
So my two examples stink, :).
I guess my point is that if the answer to a lot of people's requests is
that "they can spin things themselves", I just thought it would be an
important consideration for Fedora to give the respinners that
flexibility THROUGH modularization.
--
Richi Plana
2:28 p.m.
On 9/4/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
I guess my point is that if the answer to a lot of people's
requests is
that "they can spin things themselves", I just thought it would be an
important consideration for Fedora to give the respinners that
flexibility THROUGH modularization.
Sure, and my point is, we are attempting to do just that..where there
is real benefit. Things like virtual provides and the alternatives
system are used when it makes sense. And "where it makes sense" is
always in flux. There's an effort afoot right now to virtualize how we
deal with logos for example. There's no doubt in my mind that we are
putting thought and effort into modularizing things to make re-spins
more possible as the need arises. It helps immensely, if discussions
are grounded around real situations that would benefit from additional
modularization, and not hypotheticals. I would humbly suggest that
you take a little time and play around with repoquery as found in the
yum-utils package and explore the dependancy chains a little bit using
the tools --whatprovides, --whatrequires, --alldeps features to get a
feel for how much virtualization is being used at the packaging level.
-jef
2:44 p.m.
On Tue, 2007-09-04 at 11:28 -0800, Jeff Spaleta wrote:
Sure, and my point is, we are attempting to do just that..where
there
is real benefit. Things like virtual provides and the alternatives
system are used when it makes sense. And "where it makes sense" is
always in flux. There's an effort afoot right now to virtualize how we
deal with logos for example. There's no doubt in my mind that we are
putting thought and effort into modularizing things to make re-spins
more possible as the need arises. It helps immensely, if discussions
are grounded around real situations that would benefit from additional
modularization, and not hypotheticals. I would humbly suggest that
you take a little time and play around with repoquery as found in the
yum-utils package and explore the dependancy chains a little bit using
the tools --whatprovides, --whatrequires, --alldeps features to get a
feel for how much virtualization is being used at the packaging level.
I'm not saying you guys aren't. I'm just wondering if it's written in a
guideline somewhere or if each person has to come up with the same
realization each and every time. If there's something to show people who
might be interested in Fedora why they would want to use Fedora (because
the people working on it are smart cookies based on what they've said
they're doing).
Best practices aren't based on current nor existing problems. I do
apologize if I've wasted people's time, but I just wondered if there
would be value in having certain things written down.
And yes, I am starting to get a feel for the intricacies of the rpm and
yum utils.
--
Richi Plana
3:15 p.m.
On 9/4/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
I'm not saying you guys aren't. I'm just wondering if
it's written in a
guideline somewhere or if each person has to come up with the same
realization each and every time. If there's something to show people who
might be interested in Fedora why they would want to use Fedora (because
the people working on it are smart cookies based on what they've said
they're doing).
Introduction of a virtual provides or other mechanims..requires
discussion.. because it impacts multiple package maintainers. It's
case by case.
But it might not be so bad an idea to write a little glowy piece of
prose describing
how virtual provides are being used right now, to help people
interested in re-spinning appreciate there is more modularization at
the packaging level than the packaging list of default install of
Fedora would suggest. Until you go poking at it, you may not know its
there.
-jef
11:37 a.m.
Speaking of Modularization, The FESCo meeting announcement
(https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00373...) mentions
the proposal to pack up all kmods into the kernel package
(http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal) ... if I understand that
correctly.
While it solves the problem of having things "just work" when hardware
is introduced, it's a pale surrender to the arduous task of breaking
down the kernel into modules and detecting the hardware and pulling in
the appropriate kmod package. Here's where many people come clamoring
for a thinner, more optimized distribution. Would it be possible to come
up with a thinner spin of Fedora if all the kernel modules are in
"kernel"? How do smaller devices with limited storage use Fedora,
anyway? I know the OLPC XO device is based off of Fedora. Does it have
all the kernel mods installed, as well?
I know people like Axel Thimm are doing their best to come up with
elegant ways to package kernel modules and fix the versioning issues
associated with kernel updates. He's coming up with what he calls kmdl2.
Wouldn't Fedora be interested in his efforts? It would really be nice if
Fedora blessed a system for handling kernel modules because the external
repos seem to have their own (livna uses kmod, atrpms use kmdl, etc.)
and it confuses me. (but I could just be the minority)
--
Richi Plana
3:21 p.m.
Jeff Spaleta wrote:
On 9/4/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
> I guess my point is that if the answer to a lot of people's requests is
> that "they can spin things themselves", I just thought it would be an
> important consideration for Fedora to give the respinners that
> flexibility THROUGH modularization.
Sure, and my point is, we are attempting to do just that..where there
is real benefit. Things like virtual provides and the alternatives
system are used when it makes sense. And "where it makes sense" is
always in flux.
Has anyone considered a system that 'makes sense' for multiuser
operation where different users want different alternative targets at
once - or the same user wants alternative JVMs for different
applications at the same time?
--
Les Mikesell
lesmikesell(a)gmail.com
3:26 p.m.
On 9/4/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Has anyone considered a system that 'makes sense' for multiuser
operation where different users want different alternative targets at
once - or the same user wants alternative JVMs for different
applications at the same time?
Java has long supported this via JAVA_HOME and the like, what else do you
want?
11:12 a.m.
Colin Walters wrote:
Has anyone considered a system that 'makes sense' for multiuser
operation where different users want different alternative targets at
once - or the same user wants alternative JVMs for different
applications at the same time?
Java has long supported this via JAVA_HOME and the like, what else do
you want?
I want to know the correct JAVA_HOME and PATH settings for all the
possible JVMs when they are installed as alternatives-conforming RPM
packages but are not the system default. Is this documented somewhere?
--
Les Mikesell
lesmikesell(a)gmail.com
11:23 a.m.
On Wed, 2007-09-05 at 11:12 -0500, Les Mikesell wrote:
I want to know the correct JAVA_HOME and PATH settings for all the
possible JVMs when they are installed as alternatives-conforming RPM
packages but are not the system default. Is this documented somewhere?
It seems the current convention is to put the JAVA packages
under /usr/lib/jvm/(java|jre)-<majversion>-<vendor>-<majminversion>
with
certain packages going to /usr/lib/jvm-exports/
and /usr/lib/jvm-private/
Who's convention is this, anyway? And what's it called? It seems Fedora
and jpackage both honor this convention (and alternatives uses it. Or
maybe it's the other way around ... this convention uses was designed
around alternatives).
Just my guesses.
--
Richi Plana
11:31 a.m.
On Wednesday 05 September 2007, Richi Plana wrote:
It seems the current convention is to put the JAVA packages
under /usr/lib/jvm/(java|jre)-<majversion>-<vendor>-<majminversion>
with
certain packages going to /usr/lib/jvm-exports/
and /usr/lib/jvm-private/
Who's convention is this, anyway?
It originates from JPackage.
11:42 a.m.
On Wed, 2007-09-05 at 19:31 +0300, Ville Skyttä wrote:
It originates from JPackage.
I'm just glad there is one. And that Fedora has officially (or
unofficially) adopted it. It's sort of like the Linux Standards Base of
Java on Linux, ;).
If someone wanted to make proposals to include per-user configurations
of JVMs (possibly through a set of utilities to set JAVA_HOME and PATH),
I take it JPackage is the place to do this (the upstream) and that
Fedora will follow suit?
--
Richi Plana
11:59 a.m.
Le mercredi 05 septembre 2007 à 10:42 -0600, Richi Plana a écrit :
On Wed, 2007-09-05 at 19:31 +0300, Ville Skyttä wrote:
> It originates from JPackage.
I'm just glad there is one. And that Fedora has officially (or
unofficially) adopted it. It's sort of like the Linux Standards Base of
Java on Linux, ;).
If someone wanted to make proposals to include per-user configurations
of JVMs (possibly through a set of utilities to set JAVA_HOME and PATH),
I take it JPackage is the place to do this (the upstream) and that
Fedora will follow suit?
Any script or convention you get adopted at JPackage and included in
jpackage-utils will percolate to Fedora and many other distributions
besides. If you browse the jpackage-discuss list archive you may find
interesting exchanges on the subject (including master plans never
implemented, but that can serve as inspiration)
--
Nicolas Mailhot
12:08 p.m.
On Wed, 2007-09-05 at 18:59 +0200, Nicolas Mailhot wrote:
Any script or convention you get adopted at JPackage and included in
jpackage-utils will percolate to Fedora and many other distributions
besides. If you browse the jpackage-discuss list archive you may find
interesting exchanges on the subject (including master plans never
implemented, but that can serve as inspiration)
As with most projects. There was this proposal once to integrate wikis
and mailing list forums once (actually, it might have just gotten stuck
in my head). You know how MediaWiki has this discussion tab per page? If
that could be combined with a mailing list (web interface as well as
mail interface), it might actually be a step in the direction of taking
any good ideas and putting them in an edited, summarized and possibly
resolved state on the wiki page sans the cruft.
Thanks for the work on JPackage.
--
Richi Plana
11:46 a.m.
Le mercredi 05 septembre 2007 à 10:23 -0600, Richi Plana a écrit :
On Wed, 2007-09-05 at 11:12 -0500, Les Mikesell wrote:
> I want to know the correct JAVA_HOME and PATH settings for all the
> possible JVMs when they are installed as alternatives-conforming RPM
> packages but are not the system default. Is this documented somewhere?
It seems the current convention is to put the JAVA packages
under /usr/lib/jvm/(java|jre)-<majversion>-<vendor>-<majminversion>
with
certain packages going to /usr/lib/jvm-exports/
and /usr/lib/jvm-private/
Who's convention is this, anyway?
Originally, mine when I was active @jpp and was packaging jvms
And what's it called?
You know, you're the first person to ask this question I know of:)
The layout and its intent is described in the jpackage-1.5-policy
document shipped with jpackage utils. IIRC I wrote this file a week
after baking the layout and the associated shell scripts, so that would
date its definition around March 10, 2003.
I never thought of giving it a name. Today that would be JPackage
conventions for most people.
It seems Fedora
and jpackage both honor this convention (and alternatives uses it. Or
maybe it's the other way around ... this convention uses was designed
around alternatives).
Fedora Java packaging as it's known today is a JPackage fork
(periodically rebased). The Red Hat Java group originally started from
its own package repository IIRC, but struggled to package the Java world
and decided later to use a JPackage base as its repo was more complete.
--
Nicolas Mailhot
12:33 p.m.
Nicolas Mailhot wrote:
>> I want to know the correct JAVA_HOME and PATH settings for
all the
>> possible JVMs when they are installed as alternatives-conforming RPM
>> packages but are not the system default. Is this documented somewhere?
> It seems the current convention is to put the JAVA packages
> under /usr/lib/jvm/(java|jre)-<majversion>-<vendor>-<majminversion>
with
> certain packages going to /usr/lib/jvm-exports/
> and /usr/lib/jvm-private/
>
> Who's convention is this, anyway?
Originally, mine when I was active @jpp and was packaging jvms
> And what's it called?
You know, you're the first person to ask this question I know of:)
The layout and its intent is described in the jpackage-1.5-policy
document shipped with jpackage utils. IIRC I wrote this file a week
after baking the layout and the associated shell scripts, so that would
date its definition around March 10, 2003.
I never thought of giving it a name. Today that would be JPackage
conventions for most people.
So, where do I find the answer to the question above regarding the
correct JAVA_HOME and PATH to use a JVM that is not the system default?
How is the split exports/private directory supposed to relate to that?
> It seems Fedora
> and jpackage both honor this convention (and alternatives uses it. Or
> maybe it's the other way around ... this convention uses was designed
> around alternatives).
Fedora Java packaging as it's known today is a JPackage fork
(periodically rebased). The Red Hat Java group originally started from
its own package repository IIRC, but struggled to package the Java world
and decided later to use a JPackage base as its repo was more complete.
And what's the current situation with this now that Fedora and RHEL5
include some stuff that looks jpackage'd but isn't? How do you
control, for example, which tomcat version you install?
--
Les Mikesell
lesmikesell(a)gmail.com
12:44 p.m.
On Wed, 2007-09-05 at 12:33 -0500, Les Mikesell wrote:
So, where do I find the answer to the question above regarding the
correct JAVA_HOME and PATH to use a JVM that is not the system default?
How is the split exports/private directory supposed to relate to that?
On my system where I have java-1.5.0-sun-1.5.0.12-1jpp.x86_64 and
java-1.5.0-sun-devel-1.5.0.12-1jpp.x86_64 installed, I use
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun-1.5.0.12
# and
PATH=$JAVA_HOME/bin:$PATH
which works regardless of what alternatives has set up. If you
use /usr/bin/java, though, I assume it overwrites JAVA_HOME. But if you
just the executable loader find java, then it should use the
above-mentioned properly. At least I haven't had any issues.
And what's the current situation with this now that Fedora and
RHEL5
include some stuff that looks jpackage'd but isn't? How do you
control, for example, which tomcat version you install?
As far as I can tell, the init scripts that come with tomcat5 for Fedora
Core 6 (the only ones I've tested so far) uses $(JAVA_HOME)/bin/java ...
that's the JAVA_HOME set for the tomcat5 user. It's CATALINA_HOME is set
to /usr/share/tomcat5/ and it configured (again for the Fedora package)
via /etc/tomcat5/tomcat5.conf
--
Richi Plana
2:29 p.m.
Le mercredi 05 septembre 2007 à 12:33 -0500, Les Mikesell a écrit :
Nicolas Mailhot wrote:
>>> I want to know the correct JAVA_HOME and PATH settings for all the
>>> possible JVMs when they are installed as alternatives-conforming RPM
>>> packages but are not the system default. Is this documented somewhere?
>>
So, where do I find the answer to the question above regarding the
correct JAVA_HOME and PATH to use a JVM that is not the system default?
If the question is "what is the list of the roots of all the possible
JVMs that may be released for Linux and packaged using jpp conventions"
– no one has the answer because no one knows the JVM list in the first
place. Given the vendor name, java standard version, build number etc
one can make an educated guess because people tend to use the same
template but there is no absolute naming requirement. The packager must
choose a unique directory name and it must be under %{libdir}/jvm that's
about it.
If the question is "how does a particular jpp-packaged app choose its
JVM" the answer is it follows the JAVA_HOME env var, and which can be
set:
1. in the user environment
2. in app-specific conf file
3. in user-level conf file
4. in system-level conf file
4. or falling all that trying pre-defined fallbacks (meaning java apps
require java or java-devel, if a java package is installed
%{libdir}/jvm/jre must exist and if a java-devel package is installed
ditto for %{libdir}/jvm/java
It's the responsability of the admin or user that overrides JAVA_HOME
instead of letting the scripts fallback to the defaults to make sure
JAVA_HOME is set properly (ie if you set it as something stupid things
will go boom)
How is the split exports/private directory supposed to relate to
that?
Read the documentation bundled with jpackage-utils
> Fedora Java packaging as it's known today is a JPackage
fork
> (periodically rebased). The Red Hat Java group originally started from
> its own package repository IIRC, but struggled to package the Java world
> and decided later to use a JPackage base as its repo was more complete.
And what's the current situation with this now that Fedora and RHEL5
include some stuff that looks jpackage'd but isn't? How do you
control, for example, which tomcat version you install?
How do you control the installed apache version ? You get the one the
Fedora maintainer selected. Same for Tomcat. You get the one Fedora
selected if you source Fedora, and you get the one JPP selected if you
source JPP. And the version will change from Fedora release to Fedora
release, and JPP release to JPP release.
If you're not happy with the choices you can contribute another
parallel-installable tomcat to Fedora or JPP, they're both projects open
to external contributions. But speaking as a former Tomcat packager –
it's a beast with tentacular dependencies, so you better allocate a lot
of packaging time.
If you have more java packaging questions I suggest posting on
jpackage-discuss, and not be offended if the answer is long in coming —
the project is ressource-starved.
--
Nicolas Mailhot
3:34 p.m.
On Wed, 2007-09-05 at 21:29 +0200, Nicolas Mailhot wrote:
Le mercredi 05 septembre 2007 à 12:33 -0500, Les Mikesell a écrit :
> Nicolas Mailhot wrote:
>
> >>> I want to know the correct JAVA_HOME and PATH settings for all the
> >>> possible JVMs when they are installed as alternatives-conforming RPM
> >>> packages but are not the system default. Is this documented
somewhere?
> >>
> So, where do I find the answer to the question above regarding the
> correct JAVA_HOME and PATH to use a JVM that is not the system default?
If the question is "what is the list of the roots of all the possible
VMs that may be released for Linux and packaged using jpp conventions"
Well, one method (and this isn't official AFAIK) is to run "alternatives
--config java" or "alternatives --config javac" and that should give you
a starting point for figuring out the list of JAVA_HOME paths for
packages installed that are blessed by JPackage (or was it Fedora? since
I'm not sure where alternatives support was introduced).
--
Richi Plana
3:46 p.m.
Richi Plana wrote:
On Wed, 2007-09-05 at 21:29 +0200, Nicolas Mailhot wrote:
> Le mercredi 05 septembre 2007 à 12:33 -0500, Les Mikesell a écrit :
>> Nicolas Mailhot wrote:
>>
>>>>> I want to know the correct JAVA_HOME and PATH settings for all the
>>>>> possible JVMs when they are installed as alternatives-conforming RPM
>>>>> packages but are not the system default. Is this documented
somewhere?
>> So, where do I find the answer to the question above regarding the
>> correct JAVA_HOME and PATH to use a JVM that is not the system default?
> If the question is "what is the list of the roots of all the possible
> VMs that may be released for Linux and packaged using jpp conventions"
Well, one method (and this isn't official AFAIK) is to run "alternatives
--config java" or "alternatives --config javac" and that should give you
a starting point for figuring out the list of JAVA_HOME paths for
packages installed that are blessed by JPackage (or was it Fedora? since
I'm not sure where alternatives support was introduced).
Another method of querying and selecting blessed JPackage alternatives is
system-switch-java. It simplifies selection because it switches all relevant
master links (java, javac, plugin) to the selected vendor/version
implementations. Try:
yum install system-switch-java
Tom
4 p.m.
On Fri, 2007-09-07 at 16:46 -0400, Thomas Fitzsimmons wrote:
Richi Plana wrote:
> Well, one method (and this isn't official AFAIK) is to run "alternatives
> --config java" or "alternatives --config javac" and that should give
you
> a starting point for figuring out the list of JAVA_HOME paths for
> packages installed that are blessed by JPackage (or was it Fedora? since
> I'm not sure where alternatives support was introduced).
Another method of querying and selecting blessed JPackage alternatives is
system-switch-java. It simplifies selection because it switches all relevant
master links (java, javac, plugin) to the selected vendor/version
implementations. Try:
yum install system-switch-java
The original poster was looking for a per-user solution to JVM
switching. I'm guessing from the name (system-switch-java) that it
switches the whole system's choice of java (javac, plugin, etc.) as
opposed to just the user's. And that it probably requires some kind of
elevated access permissions. Is it a frontend to the alternatives
system?
--
Richi Plana
4:01 p.m.
Thomas Fitzsimmons wrote:
Another method of querying and selecting blessed JPackage
alternatives
is system-switch-java. It simplifies selection because it switches all
relevant master links (java, javac, plugin) to the selected
vendor/version implementations. Try:
yum install system-switch-java
Is that only in fedora 7? Also, what I'm looking for is not to switch
the system default but to find how to invoke a non-default version. If
this makes it obvious what JAVA_HOME should be it would be useful.
--
Les Mikesell
lesmikesell(a)gmail.com
3:34 p.m.
Nicolas Mailhot wrote:
>>>> I want to know the correct JAVA_HOME and PATH
settings for all the
>>>> possible JVMs when they are installed as alternatives-conforming RPM
>>>> packages but are not the system default. Is this documented somewhere?
> So, where do I find the answer to the question above regarding the
> correct JAVA_HOME and PATH to use a JVM that is not the system default?
If the question is "what is the list of the roots of all the possible
JVMs that may be released for Linux and packaged using jpp conventions"
– no one has the answer because no one knows the JVM list in the first
place.
OK, but how about the answer for the known universe of JVM's included in
the fedora/RHEL repositories plus the jpackage repository, including
the ones that don't actually contain the JVM, but do determine the
location where it will be installed?
Given the vendor name, java standard version, build number etc
one can make an educated guess because people tend to use the same
template but there is no absolute naming requirement. The packager must
choose a unique directory name and it must be under %{libdir}/jvm that's
about it.
If the question is "how does a particular jpp-packaged app
choose its
JVM" the answer is it follows the JAVA_HOME env var, and which can be
set:
1. in the user environment
2. in app-specific conf file
3. in user-level conf file
4. in system-level conf file
4. or falling all that trying pre-defined fallbacks (meaning java apps
require java or java-devel, if a java package is installed
%{libdir}/jvm/jre must exist and if a java-devel package is installed
ditto for %{libdir}/jvm/java
It's the responsability of the admin or user that overrides JAVA_HOME
instead of letting the scripts fallback to the defaults to make sure
JAVA_HOME is set properly (ie if you set it as something stupid things
will go boom)
No, I wouldn't limit a question like that to just packaged apps. The
main issue is whether everything expected to be under JAVA_HOME is still
in the correct relative position with all the matching binaries in
$JAVA_HOME/bin.
> How is the split exports/private directory supposed to relate to
that?
Read the documentation bundled with jpackage-utils
$ rpm -q jpackage-utils
jpackage-utils-1.7.3-1jpp.3.fc6
$ man jpackage-utils
No manual entry for jpackage-utils
Does jpackage have its own convention about what to do with
documentation as well?
>> Fedora Java packaging as it's known today is a JPackage
fork
>> (periodically rebased). The Red Hat Java group originally started from
>> its own package repository IIRC, but struggled to package the Java world
>> and decided later to use a JPackage base as its repo was more complete.
> And what's the current situation with this now that Fedora and RHEL5
> include some stuff that looks jpackage'd but isn't? How do you
> control, for example, which tomcat version you install?
How do you control the installed apache version ?
I didn't know anyone offered more than one.
You get the one the
Fedora maintainer selected. Same for Tomcat. You get the one Fedora
selected if you source Fedora, and you get the one JPP selected if you
source JPP. And the version will change from Fedora release to Fedora
release, and JPP release to JPP release.
What if you source both fedora and jpackage repositories? Is that not a
reasonable thing to do? Or you need both tomcat4 and 5 installed on the
same machine?
If you're not happy with the choices you can contribute another
parallel-installable tomcat to Fedora or JPP, they're both projects open
to external contributions.
I did not have any problem installing both tomcat4 and tomcat55 from the
jpackage repo before fedora/RHEL incorporated parts that don't seem to
play well with others.
But speaking as a former Tomcat packager –
it's a beast with tentacular dependencies, so you better allocate a lot
of packaging time.
That's precisely the sort of thing that you want someone else to get
right in the repositories. I can do the easy stuff myself...
If you have more java packaging questions I suggest posting on
jpackage-discuss, and not be offended if the answer is long in coming —
the project is ressource-starved.
No, I'm more interested in the relationship between the embedded
jpackage-looking stuff in fedora/RHEL5 and whether it is intended to
break access to jpackage. Or if they are supposed to work together, how
do you do it?
--
Les Mikesell
lesmikesell(a)gmail.com
3:55 p.m.
On Wed, 2007-09-05 at 15:34 -0500, Les Mikesell wrote:
OK, but how about the answer for the known universe of JVM's
included in
the fedora/RHEL repositories plus the jpackage repository, including
the ones that don't actually contain the JVM, but do determine the
location where it will be installed?
This is what I'm starting to learn: supposedly, something like
"repoquery --whatprovides java-sdk" or "repoquery --whatprovides
java-jre" is the way to go. It's a virtual Provides thing, but when I
checked, JPackage's packages didn't come up (perhaps because they don't
provide binary packages or maybe the virtual Provides).
The rpm, yum and repo query mechanisms coupled with their virtual
provides are proving to be pretty cool.
P.S. Change of Subject: and thread?
--
Richi Plana
4:02 p.m.
On Wed, 2007-09-05 at 14:55 -0600, Richi Plana wrote:
This is what I'm starting to learn: supposedly, something like
"repoquery --whatprovides java-sdk" or "repoquery --whatprovides
java-jre" is the way to go. It's a virtual Provides thing, but when I
checked, JPackage's packages didn't come up (perhaps because they don't
provide binary packages or maybe the virtual Provides).
Whoops. Typo. That should be "repoquery --whatprovides jre"
And it turns out that I don't have the JPackage repo configured in my
yum repo list so disregard what I said.
--
Richi Plana
4:09 p.m.
On Wed, 2007-09-05 at 14:55 -0600, Richi Plana wrote:
On Wed, 2007-09-05 at 15:34 -0500, Les Mikesell wrote:
> OK, but how about the answer for the known universe of JVM's included in
> the fedora/RHEL repositories plus the jpackage repository, including
> the ones that don't actually contain the JVM, but do determine the
> location where it will be installed?
This is what I'm starting to learn: supposedly, something like
"repoquery --whatprovides java-sdk" or "repoquery --whatprovides
java-jre" is the way to go. It's a virtual Provides thing, but when I
checked, JPackage's packages didn't come up (perhaps because they don't
provide binary packages or maybe the virtual Provides).
The rpm, yum and repo query mechanisms coupled with their virtual
provides are proving to be pretty cool.
P.S. Change of Subject: and thread?
I just added a patch to repoquery to allow it to handle arbitrary url
as repos. So you can:
repoquery --repofrompath=http://some/repo/I/want/toquery
--repofrompath=/some/local/path/also --repoid=toquery --repoid=also -q
-a
and it will grab the metadata from those to repositories and query them
instead.
-sv
1:08 a.m.
Le mercredi 05 septembre 2007 à 15:34 -0500, Les Mikesell a écrit :
Nicolas Mailhot wrote:
>>>>> I want to know the correct JAVA_HOME and PATH settings for all the
>>>>> possible JVMs when they are installed as alternatives-conforming RPM
>>>>> packages but are not the system default. Is this documented
somewhere?
>> So, where do I find the answer to the question above regarding the
>> correct JAVA_HOME and PATH to use a JVM that is not the system default?
>
> If the question is "what is the list of the roots of all the possible
> JVMs that may be released for Linux and packaged using jpp conventions"
> – no one has the answer because no one knows the JVM list in the first
> place.
OK, but how about the answer for the known universe of JVM's included in
the fedora/RHEL repositories plus the jpackage repository, including
the ones that don't actually contain the JVM, but do determine the
location where it will be installed?
For the FLOSS ones you can use yum tricks
For the non-FLOSS ones you have to assemble them yourself starting from
the non-free material @jpp, and you can check the paths at the same
time.
A jpp-style repository does *not* maintain a central JVM list. That's
how it was done before I wrote the "new" guidelines in 2003 and it was
hell to maintain. In a jpp-style repository any jvm that drops
directories in the right place may be used through alternatives, but the
rest of the system need not care about the jvms that may or may not be
packaged this way.
If you want to bring back central lists from the dead you're welcome to
try, but anyone who touched pre-1.5 jpp won't follow you. For more
information, read jpackage-discuss archives around march 2003.
--
Nicolas Mailhot
1:57 a.m.
Nicolas Mailhot wrote:
> OK, but how about the answer for the known universe of JVM's
included in
> the fedora/RHEL repositories plus the jpackage repository, including
> the ones that don't actually contain the JVM, but do determine the
> location where it will be installed?
For the FLOSS ones you can use yum tricks
For the non-FLOSS ones you have to assemble them yourself starting from
the non-free material @jpp, and you can check the paths at the same
time.
A jpp-style repository does *not* maintain a central JVM list. That's
how it was done before I wrote the "new" guidelines in 2003 and it was
hell to maintain. In a jpp-style repository any jvm that drops
directories in the right place may be used through alternatives, but the
rest of the system need not care about the jvms that may or may not be
packaged this way.
I could have sworn I ran into dependencies on specific JVM versions when
trying to install some packages from the jpackage repo. How can that be
if you don't keep track of the JVMs themselves? Or if the packages are
supposed to be usable with unpackaged JVMs?
If you want to bring back central lists from the dead you're
welcome to
try, but anyone who touched pre-1.5 jpp won't follow you. For more
information, read jpackage-discuss archives around march 2003.
I don't particularly care how the files are managed or where they live.
I'm just trying to learn how to find what alternatives are available
and how to access them when certain apps require different JVMs and you
want to run them at the same time - and I haven't found much
documentation on the topic.
--
Les Mikesell
lesmikesell(a)gmail.com
2:54 a.m.
Le Jeu 6 septembre 2007 08:57, Les Mikesell a écrit :
How can that be
if you don't keep track of the JVMs themselves? Or if the packages are
supposed to be usable with unpackaged JVMs?
They are *not* supposed to be usable with unpackaged JVMs. Sorry. JPP
won't maintain a huge pile of workarounds just because vendors are too
lazy to follow common conventions and stick to them. Sometimes people
release an adaptation layer for a specific vendor jvm and yes this
layer is specific to this jvm but that's about it.
I don't particularly care how the files are managed or where
they
live.
Then you won't ever understand why something works or not and how to
fix your problems. The default is "just use the system jvm" if you
don't want to follow the defaults you have to understand the
conventions. That means reading the docs not deciding beforehand
what's relevant and what's not.
--
Nicolas Mailhot
8:15 a.m.
Nicolas Mailhot wrote:
Le Jeu 6 septembre 2007 08:57, Les Mikesell a écrit :
> How can that be
> if you don't keep track of the JVMs themselves? Or if the packages are
> supposed to be usable with unpackaged JVMs?
They are *not* supposed to be usable with unpackaged JVMs.
That seems philosophically very wrong. Somewhat like not being able to
put an ogg file on your computer unless it is bundled with a known
version of a known player packaged with the same packaging conventions.
Sorry. JPP
won't maintain a huge pile of workarounds just because vendors are too
lazy to follow common conventions and stick to them. Sometimes people
release an adaptation layer for a specific vendor jvm and yes this
layer is specific to this jvm but that's about it.
That's not supposed to be the case. If you supply the right JAVA_HOME
and start the right initial binary, it shouldn't matter where the actual
location is or anything about how it was packaged. And in fact that is
the case if you drop the sun binary under /usr/java and run things with
it instead of the arbitrarily moved jpackage version that you have to
have to do the app installs from the jpackage repo.
> I don't particularly care how the files are managed or where
they
> live.
Then you won't ever understand why something works or not and how to
fix your problems.
By "don't care" I mean I consider it completely arbitrary and have no
preference, not that I don't want to know. It's just annoying that the
packaged location is different from what Sun uses in their RPM version
and Sun should be somewhat of an authority on matters pertaining to java
- and even more annoying that in this long chain of questions I still
don't have the simple answer of where JAVA_HOME has been hidden for some
small variety of JVMs. I _do_ want to know that, but don't have much
interest in "understanding" arbitrary choices of paths that someone has
already made.
The default is "just use the system jvm" if you
don't want to follow the defaults you have to understand the
conventions. That means reading the docs not deciding beforehand
what's relevant and what's not.
Please, please - point me at the doc that says what JAVA_HOME is for
some (any?) jvm that has been hidden in the alternatives scheme of
symlinks. Preferable a document aimed at describing how to deal with an
already made choice of location and execute it, not the philosophy of
why the location and depth of symlinks that hide it was chosen.
The only philosophical concept I'm interested in here is that more than
one jvm can be run at once - and that should be expected if for nothing
else but testing under the next JVM release while keeping the old
version running in production.
--
Les Mikesell
lesmikesell(a)gmail.com
11:43 a.m.
Le jeudi 06 septembre 2007 à 08:15 -0500, Les Mikesell a écrit :
That seems philosophically very wrong.
...
That's not supposed to be the case.
...
It's just annoying that the
packaged location is different from what Sun uses
...
and Sun should be somewhat of an authority on matters pertaining to
java
1. You're welcome to found a better designed Java packaging project.
2. SUN didn't care at all about the Java deployment problem space till
it got sidelined by .Net and OSGi/Eclipse on the other. SUN's solution
to the problem is JSR 277, which won't be deployed anywhere before Java
7 (mid-2008 at the earliest) and it remains to be seen if it will fly,
crash or be rpm-compatible.
- and even more annoying that in this long chain of questions I still
don't have the simple answer
You were given information but chose not to listen. I won't waste any
more time on the subject.
--
Nicolas Mailhot
3:15 p.m.
Nicolas Mailhot wrote:
Le jeudi 06 septembre 2007 à 08:15 -0500, Les Mikesell a écrit :
> That seems philosophically very wrong.
...
Do you disagree with the idea that a JVM executing java bytecode should
be very much like a media player playing a media file? That is,
installing the data should not be dependent on having some particular
player or JVM available that might or might not be used to manipulate it
later. Why can't I have the app before the JVM or supply my own JVM?
> That's not supposed to be the case.
...
> It's just annoying that the
> packaged location is different from what Sun uses
...
> and Sun should be somewhat of an authority on matters pertaining to java
1. You're welcome to found a better designed Java packaging project.
Do any of them understand that unix-like systems are multi-tasking and
multi-user by nature, and that some of those multiple tasks and multiple
user preferences are going to be different versions of the same thing on
the same machine at the same time? Apparently you do really get this at
the application level if you were involved in building the packaged
tomcat4/tomcat55 versions that can co-exist and do provide an obvious
way to let the user distinguish between them.
2. SUN didn't care at all about the Java deployment problem space
till
it got sidelined by .Net and OSGi/Eclipse on the other. SUN's solution
to the problem is JSR 277, which won't be deployed anywhere before Java
7 (mid-2008 at the earliest) and it remains to be seen if it will fly,
crash or be rpm-compatible.
What does that mean? Sun has had downloadable RPMs for a long time.
Jpackage just doesn't work with them due to arbitrarily different
locations. And I don't see why there is any more relationship between
the apps and the jvm than there would be between a source package and
any number of compilers that might be used with it later.
> - and even more annoying that in this long chain of questions I
still
> don't have the simple answer
You were given information but chose not to listen. I won't waste any
more time on the subject.
No one has given a usable answer for even a single value of JAVA_HOME
for a single packaged jvm version. Or the location of the document that
provides this necessary information. I'm sorry if that was too much to
ask.
--
Les Mikesell
lesmikesll(a)gmail.com
6:17 p.m.
On Thu, 2007-09-06 at 15:15 -0500, Les Mikesell wrote:
Nicolas Mailhot wrote:
> Le jeudi 06 septembre 2007 à 08:15 -0500, Les Mikesell a écrit :
>
>> That seems philosophically very wrong.
>
> ...
Do you disagree with the idea that a JVM executing java bytecode should
be very much like a media player playing a media file? That is,
installing the data should not be dependent on having some particular
player or JVM available that might or might not be used to manipulate it
later. Why can't I have the app before the JVM or supply my own JVM?
Probably not the best example. A piece of data (a media file in your
example) has so many different kinds of applications associated with it,
some might even be on different systems and the data is exported via a
number of means (http, nfs, etc.) Java bytecode, unless they're applets,
are much easier to predict requirements for. There is a huge probability
that they will need a JVM, and unlike media players, from outside,
they're designed to function in the same way.
As examples go, it's closer to say that JVMs are to Java applications or
even just bytecode what glibc is to native applications.
In Fedora, openoffice.org-core-2.2.0 Requires the virtual package java.
You CAN have the app before the JVM, I suppose, the same way you can
"rpm --nodeps -ivh openoffice.org-core.2.2.0....", but they'd just be
bytes taking up space in your filesystem.
No one has given a usable answer for even a single value of JAVA_HOME
for a single packaged jvm version. Or the location of the document that
provides this necessary information. I'm sorry if that was too much to
ask.
Honestly, I tried to answer here
(https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00396...), here
(https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00414...) and here
(https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00490...), but I
guess I'm misunderstanding the question.
--
Richi Plana
11:05 p.m.
Richi Plana wrote:
> Do you disagree with the idea that a JVM executing java bytecode
should
> be very much like a media player playing a media file? That is,
> installing the data should not be dependent on having some particular
> player or JVM available that might or might not be used to manipulate it
> later. Why can't I have the app before the JVM or supply my own JVM?
Probably not the best example. A piece of data (a media file in your
example) has so many different kinds of applications associated with it,
some might even be on different systems and the data is exported via a
number of means (http, nfs, etc.) Java bytecode, unless they're applets,
are much easier to predict requirements for.
Is there some problem running an application where the bytecode is on a
different machine than the jvm, using nfs?
There is a huge probability
that they will need a JVM, and unlike media players, from outside,
they're designed to function in the same way.
I'm not sure I understand. Shouldn't you be able to use any version of
a jvm, packaged or not, without specific dependencies, just like you
could use different media players to play the same file? Or even run
more than one of them at once?
As examples go, it's closer to say that JVMs are to Java
applications or
even just bytecode what glibc is to native applications.
Things may be that close-coupled in practice but only because of lack of
conformance to the specification. It should be more like claiming that
C source code is dependent on one gcc version or some other specific
compiler. In some cases that may be true, but it doesn't seem right to
encourage such bugginess with permanent workarounds.
In Fedora, openoffice.org-core-2.2.0 Requires the virtual package
java.
You CAN have the app before the JVM, I suppose, the same way you can
"rpm --nodeps -ivh openoffice.org-core.2.2.0....", but they'd just be
bytes taking up space in your filesystem.
Will it work later then if I provide a different JVM than the packaged
versions?
> No one has given a usable answer for even a single value of
JAVA_HOME
> for a single packaged jvm version. Or the location of the document that
> provides this necessary information. I'm sorry if that was too much to
> ask.
Honestly, I tried to answer here
(https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00396...), here
(https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00414...) and here
(https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00490...), but I
guess I'm misunderstanding the question.
Yes, thanks, and sorry - I missed the one actual answer in the first
link, but I was confused by the comment somewhere about parts going to
private and export directories that didn't seem to be under the same top
level. Is everything expected to be under JAVA_HOME actually still in
one place?
--
Les Mikesell
lesmikesell(a)gmail.com
9:14 a.m.
On Thu, 2007-09-06 at 23:05 -0500, Les Mikesell wrote:
Is there some problem running an application where the bytecode is on
a
different machine than the jvm, using nfs?
No, of course not. That's what applets are designed for. Same with
NFS-exported applications, but I'm thinking as real-world usage go, it's
much less likely. But then, that's why there are overrides like --nodeps
on rpm, I guess, just not on yum.
> There is a huge probability
> that they will need a JVM, and unlike media players, from outside,
> they're designed to function in the same way.
I'm not sure I understand. Shouldn't you be able to use any version of
a jvm, packaged or not, without specific dependencies, just like you
could use different media players to play the same file? Or even run
more than one of them at once?
Sorry, that was a bit vague. I just meant that a piece of java bytecode
is usually designed to be executed in one way (either as a java
application, web application, applet, etc.) or 2 or 3 at the most. Media
files can be used in so many ways, not just playing them (editing,
converting, analysis, etc.) Anyway, the point is that it's just not the
best example to illustrate your point, and not that it doesn't.
> In Fedora, openoffice.org-core-2.2.0 Requires the virtual
package java.
>
> You CAN have the app before the JVM, I suppose, the same way you can
> "rpm --nodeps -ivh openoffice.org-core.2.2.0....", but they'd just be
> bytes taking up space in your filesystem.
Will it work later then if I provide a different JVM than the packaged
versions?
If both openoffice.org-core's Java requirements match those that the JVM
installed's featureset provides, then yes. (And better if it's because
they fully comply with JSRs for that version of Java(TM)). That's the
beauty of modularity.
Yes, thanks, and sorry - I missed the one actual answer in the first
link, but I was confused by the comment somewhere about parts going to
private and export directories that didn't seem to be under the same top
level. Is everything expected to be under JAVA_HOME actually still in
one place?
I honestly don't know. 1) So far, it's worked for me, 2) looking at the
contents of the JRE (java-1.5.0-(sun|ibm)), it seems that apart from a
couple of JAR files located in jvm-exports/ and jvm-private/, all the
files are in (quotes) "$JAVA_HOME". Anybody read the pertinent JSR on
JAVA_HOME directory layouts care to comment?
--
Richi Plana
2:44 p.m.
Richi Plana wrote:
> I'm not sure I understand. Shouldn't you be able to use
any version of
> a jvm, packaged or not, without specific dependencies, just like you
> could use different media players to play the same file? Or even run
> more than one of them at once?
Sorry, that was a bit vague. I just meant that a piece of java bytecode
is usually designed to be executed in one way (either as a java
application, web application, applet, etc.) or 2 or 3 at the most. Media
files can be used in so many ways, not just playing them (editing,
converting, analysis, etc.) Anyway, the point is that it's just not the
best example to illustrate your point, and not that it doesn't.
OK, the likely scenarios are that you have different apps that only work
with one JVM each, and even with one app you always want to be able to
test it under different JVM verions (including the next update) before
thinking about changing the system default.
> Yes, thanks, and sorry - I missed the one actual answer in the
first
> link, but I was confused by the comment somewhere about parts going to
> private and export directories that didn't seem to be under the same top
> level. Is everything expected to be under JAVA_HOME actually still in
> one place?
I honestly don't know. 1) So far, it's worked for me, 2) looking at the
contents of the JRE (java-1.5.0-(sun|ibm)), it seems that apart from a
couple of JAR files located in jvm-exports/ and jvm-private/, all the
files are in (quotes) "$JAVA_HOME". Anybody read the pertinent JSR on
JAVA_HOME directory layouts care to comment?
The answer I have really been looking for is that the concept of
JAVA_HOME reliably still exists, and how to use it in spite of the
efforts to hide where it lives in the alternatives universe.
--
Les Mikesell
lesmikesell(a)gmail.com
3:45 a.m.
On Thu, 2007-09-06 at 08:15 -0500, Les Mikesell wrote:
It's just annoying that the
packaged location is different from what Sun uses in their RPM version
and Sun should be somewhat of an authority on matters pertaining to java
Sun is certainly no authority on how Fedora should build rpms or how
GNU/Linux systems should organise directories. But the nice thing is,
they're now sort of following the JPackage conventions in their official
Java 1.6 RPM:s, so no need for JPackage rpms. Just run their install
script (which they confusingly call a self-extracting archive), and you
get some rpms installed which interact nicely with alternatives.
- and even more annoying that in this long chain of questions I still
don't have the simple answer of where JAVA_HOME has been hidden for some
small variety of JVMs.
Uhm... They're all very consistently placed in /usr/lib/jvm, each
directory there is a JAVA_HOME. I wouldn't call that hidden. It's a nice
scheme. And Richi Plana pointed out how to set JAVA_HOME already...
/abo
10:03 a.m.
On Thu, 2007-09-06 at 01:57 -0500, Les Mikesell wrote:
I could have sworn I ran into dependencies on specific JVM versions
when
trying to install some packages from the jpackage repo. How can that be
if you don't keep track of the JVMs themselves? Or if the packages are
supposed to be usable with unpackaged JVMs?
I don't particularly care how the files are managed or where they live.
I'm just trying to learn how to find what alternatives are available
and how to access them when certain apps require different JVMs and you
want to run them at the same time - and I haven't found much
documentation on the topic.
As far as I know, there's the gcj version that comes with Fedora. Fedora
8 will / might have the IcedTea version but is already available for
download from fedora-development (rawhide). If you scroll down to the
"Non-Free" section of JPackage.org
(http://www.jpackage.org/browser/browse.php?jppversion=1.7 or the older
http://www.jpackage.org/browser/browse.php?jppversion=1.6), you'll find
that there are JVMs available from Sun, IBM and BEA. Those JVMs aren't
packaged with the binaries because of some licensing thing (I'm
guessing). You'll have to download the packages from the source website
and build the Fedora RPM packages using the nosrc.rpm's that JPackage
provides.
Those are the alternative JVMs that I'm aware of. I can see why they
might put JVM-specific dependencies on some packages. I've had Eclipse
break on me using IBM's JVM (ironically) but work on Sun's. JPackage
just can't package the binaries.
--
Richi Plana
3:27 p.m.
On 9/4/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Has anyone considered a system that 'makes sense' for
multiuser
operation where different users want different alternative targets at
once - or the same user wants alternative JVMs for different
applications at the same time?
Are you suggesting that the alternatives system, in association with
shell PATH variables isn't adequate enough for a user who knows enough
about things such as sendmail alternatives to reconfigure to their
hearts content? I'm pretty sure alternatives allows for per-user
configurations, into per-user defined paths for executables and
manpages and what not.
-jef
4:38 p.m.
Jeff Spaleta wrote:
On 9/4/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> Has anyone considered a system that 'makes sense' for multiuser
> operation where different users want different alternative targets at
> once - or the same user wants alternative JVMs for different
> applications at the same time?
Are you suggesting that the alternatives system, in association with
shell PATH variables isn't adequate enough for a user who knows enough
about things such as sendmail alternatives to reconfigure to their
hearts content?
MTA's are sort-of system wide by nature, since only one thing can be
listening on the inbound port. I'm more concerned with different JVMs
since it is fairly likely that some users/applications won't be
satisfied with included version(s), and some apps that you might want to
run at the same time require different JVM versions.
I'm pretty sure alternatives allows for per-user
configurations, into per-user defined paths for executables and
manpages and what not.
I haven't found documentation for the alternatives system that explains
it at that level, and I haven't had a strong enough stomach to wade my
way through the multi-level symlink morass to figure out what the right
values for JAVA_HOME and PATH should be to execute any specific JVM
version. Is it really designed to handle that?
--
Les Mikesell
lesmikesell(a)gmail.com
5:41 p.m.
On Tue, 2007-09-04 at 15:21 -0500, Les Mikesell wrote:
Has anyone considered a system that 'makes sense' for
multiuser
operation where different users want different alternative targets at
once - or the same user wants alternative JVMs for different
applications at the same time?
Perhaps for certain things, alternative isn't the correct device to use.
Personally, I set JAVA_HOME (along with PATH=$JAVA_HOME/bin:$PATH). For
other packages, I still do PATH=$PACKAGE/bin:$PATH and LD_LIBRARY_PATH=
$PACKAGE/lib:$LD_LIBRARY_PATH. It's old-school but it still works,
specially on a per-user level.
--
Richi Plana
6102
days inactive
6117
days old
61 comments
14 participants
participants (14)
-
Alexander Boström -
Bernie Innocenti -
Bill Crawford -
Bill Nottingham -
Bruno Wolff III -
Colin Walters -
Jef Spaleta -
Les Mikesell -
Nicolas Mailhot -
Richi Plana -
Seth Vidal -
Thomas Fitzsimmons -
Todd Zullinger -
Ville Skyttä