lsb-discuss is far from dead (was: LSB packaginganyone?)

Okay, now I'm gonna cross-post the reply to lsb-discuss
list as there was an actual LSB request in there.

===

>On 8/24/06, Axel Thimm <Axel.Thimmatrpms.net> wrote:
>> Correction: After Mats pointing out in PM that the
list is far from
>> dead, I checked and my statement applies to 
>freestandards-fhs-discuss,
>> not lsb-discuss. lsb-discuss seems to be very
healthy in list volume
>> and even has an archive (in contrast to
freestandards-fhs-discuss):
>>
>>         
http://lists.freestandards.org/pipermail/lsb-discuss
>>
>> Sincere apologies for the FUD.

Info:

There *is* an archive for freestandards-fhs-discuss as well.
http://sourceforge.net/mailarchive/forum
.php?forum=freestandards-fhs-dis
cuss

The list info page is at:
https://lists.sourceforge.net/lists/listin
fo/freestandards-fhs-discuss

No, there's not been much actual activity for a long time.

===
JBJ writes:

>You're forgiven because you posted the link to the LSB
mailing list.
>I've always had a hard time finding.
>
>Meanwhile, I note that there are many msgs about
additional
>sysconf entries.
>
>Since the elements in the sysconf set are definitely
within
>LSB standards control, I point out that rpm-4.4.4 (I
fergit) has
>the ability to resolve dependencies against getconf
symbols.
>
>One can see the runtime getconf(...) dependency name
space by running
>
>    $ rpm -v --showrc        # hmmm, gonna have to add
--showmacros
>     ...
>     Features provided by current getconf:
>     ...
>     getconf(GNU_LIBPTHREAD_VERSION) = NPTL-2.4.90
>
>While many of the getconf(...) dependencies are rather
useless,
>the dependency
>     Requires: getconf(GNU_LIBPTHREAD_VERSION) = NPTL
>is absolutely essential to indicate that rpm compiled
+NPTL
>has a prayer of functioning correctly.
>
>Is it possible to get dependencies derived from
getconf(1) spew
>permitted in the LSB packagingh standard?
>
>The dependencies would map to tests in .deb packages by 
>invoking getconf(1), not hard.

Let's look at that.

LSB folks, anybody have any comments?
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Thursday, 24 August 2006, at 09:43:37 (-0700),
Wichmann, Mats D wrote:

> > Is it possible to get dependencies derived from
getconf(1) spew
> > permitted in the LSB packagingh standard?
> >
> > The dependencies would map to tests in .deb
packages by invoking
> > getconf(1), not hard.
> 
> Let's look at that.

I think this is a good, portable approach.

My personal experience with LSB is that the concept is good
but the
follow-through isn't.  I was unable to find a working
certification
suite, up-to-date standards documents, etc.  This was awhile
back, so
it's possible it's been fixed since then.

I don't really think the LSB should be dictating how
dependencies
between packages are allowed to work within the distro
itself.  ISV
packages should require some or all of the LSB capabilities
as needed,
and distro vendors should supply packages providing these
capabilities
the ISV packages depend on.  Which distro packages
provide/require
what is really not the issue -- it's the ABI provided by
the distro
and required by the ISV software.

I don't know much about dpkg or alien's capabilities, but
what about
an lsb(FOO) namespace for LSB compliance instead of
dictating regular
dependencies?

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "The key to success?  Work hard, stay focused, and
marry a Kennedy."
                                              -- Arnold
Schwarzenegger
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 24, 2006, at 9:17 PM, Michael Jennings wrote:


>
> I don't know much about dpkg or alien's capabilities,
but what about
> an lsb(FOO) namespace for LSB compliance instead of
dictating regular
> dependencies?
>

The issue with lsb(foo) syntax is compatibility with other
LSB  
package formats, namely .deb and .tar.

The "lsb-" prefix was deemed more universal,
certainly is.

All that's really needed for a rpm name space is a way to
identify  
lsb deps from other deps.

A "lsb-" prefix is workable for LSB only deps,
even if a bit awkward  
and stiff from a rpm POV.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Thursday, 24 August 2006, at 21:25:02 (-0400),
Jeff Johnson wrote:

> The issue with lsb(foo) syntax is compatibility with
other LSB
> package formats, namely .deb and .tar.
> 
> The "lsb-" prefix was deemed more
universal, certainly is.
> 
> All that's really needed for a rpm name space is a way
to identify  
> lsb deps from other deps.
> 
> A "lsb-" prefix is workable for LSB only
deps, even if a bit awkward
> and stiff from a rpm POV.

Darn, I was afraid of that.

Though wouldn't that also apply to the getconf() stuff as
well?

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "You are waiting on a beach.  This is where the East
meets West.
  And as another sun sets on your anger, the darkness laughs
as the
  wound destroys, and it turns your prayers to noise.  Will
you
  forgive?  Will you forget?  Will you live what you know? 
He left
  his rights; will you leave yours?  You don't understand
it.
  Let it go."                                         
    -- Newsboys
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 24, 2006, at 9:28 PM, Michael Jennings wrote:

>
>
> Darn, I was afraid of that.
>
> Though wouldn't that also apply to the getconf() stuff
as well?
>

What saves getconf(...) is getconf(1), so what's a
dependency test  
for rpm becomes
a /usr/bin/getconf invocation for .deb and .tar.

But yes, alien would have to be taught the secret sauce
voodoo.

There's certainly more than rpm that needs a way to test if
+NPTL or  
not, think
about all the java changes, like size of stack, that are
tied into  
LD_ASSUME_KERNEL.

But perhaps that's a different issue than detecting if
+NPTL.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Thursday, 24 August 2006, at 21:37:32 (-0400),
Jeff Johnson wrote:

> What saves getconf(...) is getconf(1), so what's a
dependency test
> for rpm becomes a /usr/bin/getconf invocation for .deb
and .tar.

Gotcha.

> But yes, alien would have to be taught the secret sauce
voodoo.

Okay, that makes sense then.

> There's certainly more than rpm that needs a way to
test if +NPTL or
> not, think about all the java changes, like size of
stack, that are
> tied into LD_ASSUME_KERNEL.
> 
> But perhaps that's a different issue than detecting if
+NPTL.

That's an interesting point.  Should the assumptions tied
to
LD_ASSUME_KERNEL be split out into individual dependencies
or
encompassed under a single umbrella?

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/ 
<mejkainx.org>
n + 1, Inc., http://www.nplus1.net/    
  Author, Eterm (www.eterm.org)
------------------------------------------------------------
-----------
 "Your Plan and the stuff that comes out of my asshole
bear a
  suspicious resemblance to each other."            --
"The Long Walk"
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 24, 2006, at 9:44 PM, Michael Jennings wrote:

>
>
> That's an interesting point.  Should the assumptions
tied to
> LD_ASSUME_KERNEL be split out into individual
dependencies or
> encompassed under a single umbrella?
>

LD_ASSUME_KERNEL issues really should not be tracked in LSB
packaging.

The issue I was remembering was in WebSphere, which is
already
unlikely to ever appear in LSB packaging.

The per-thread stack size was increased from 2MB to 8MB for
java  
iirc, and the change
was controlled by LD_ASSUME_KERNEL.

I don't see a per-thread stack size in the getconf(1) spew,
mebbe  
hidden in one of these:

_POSIX_THREADS                     200112
_POSIX_THREAD_ATTR_STACKADDR       200112
_POSIX_THREAD_ATTR_STACKSIZE       200112


Or the change might be "unspecified" within
current standards.

No biggie, I certainly don't do java, nor is getconf(1) the
way I would
try to identify what the per-thread stack size is, I was
just looking
for other items in getconf that might be useful for LSB
package deps.

73 de Jeff

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 24, 2006, at 9:44 PM, Michael Jennings wrote:

>
>
> That's an interesting point.  Should the assumptions
tied to
> LD_ASSUME_KERNEL be split out into individual
dependencies or
> encompassed under a single umbrella?
>

LD_ASSUME_KERNEL issues really should not be tracked in LSB
packaging.

The issue I was remembering was in WebSphere, which is
already
unlikely to ever appear in LSB packaging.

The per-thread stack size was increased from 2MB to 8MB for
java  
iirc, and the change
was controlled by LD_ASSUME_KERNEL.

I don't see a per-thread stack size in the getconf(1) spew,
mebbe  
hidden in one of these:

_POSIX_THREADS                     200112
_POSIX_THREAD_ATTR_STACKADDR       200112
_POSIX_THREAD_ATTR_STACKSIZE       200112


Or the change might be "unspecified" within
current standards.

No biggie, I certainly don't do java, nor is getconf(1) the
way I would
try to identify what the per-thread stack size is, I was
just looking
for other items in getconf that might be useful for LSB
package deps.

73 de Jeff

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel