LSB packaging anyone?

<snip>
> Basically, all that is necessary to convert most any
existing rpm
> package to LSB standard
> packaging is:
> 	a) discard all dependencies except "LSB"
and "lsb-*" from
headers
> 	b) discard any/all trigger scripts.
> 	c) rewrite headers with absolute file paths instead of
the
> {dirname,basename,dirindex}
> 	that has been used in rpm many years now.
> 
> I can write that conversion program in a day or so
whenever.
> 
> What I've been muddling since OLS is whether to add a
--lsb option to
> rpmbuild
> to accomplish LSB packaging instead. I currently lean
towards a
> conversion
> utility rather than a build option (which is even less
than a couple
> of hours of
> work), because LSB packages lack sufficient information
to be
> installed on
> most current linux distros, and I'd rather not see
rpmbuild --lsb be
> used to,
> say, produce packages without dependencies that cannot
be installed
> reliably.
> 
> Is there any interest in producing LSB
"standard" packaging?
My real interest is in having sane standards.  I've never
quite
understood a and b, but certainly not a.  b (no triggers) is
understandable from a simplification point of view, but
triggers have
been here and stable for quite a while.  I still counsel
people to not
use them unless they really have to do so (for the same
reason I counsel
not to use call backs unless you really have to...more
complex debugging
for my simple little brain).

But if they are not up to discussion of changing their rpm
standards to
be more in line with reality (I really mean no
disrespect...that is just
the honest way that part of LSB hits me) then I guess a
conversion tool
might be in line, but who is it going to help since it would
not be
possible to install anything correctly?

I don't think I really answered anything here...james
 

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

On Aug 24, 2006, at 9:02 AM, Oden, James wrote:

> My real interest is in having sane standards.  I've
never quite
> understood a and b, but certainly not a.  b (no
triggers) is
> understandable from a simplification point of view, but
triggers have
> been here and stable for quite a while.  I still
counsel people to not
> use them unless they really have to do so (for the same
reason I  
> counsel
> not to use call backs unless you really have to...more
complex  
> debugging
> for my simple little brain).
>

Hehe, I never understood forbidding triggers in LSB packages
either.

Stuart explained why triggers were forbidden:
     The alien implementation cannot convert triggers.

If anyone had bothered to tell me that years ago, I would
have
sent a patch to Joey Hess in a matter of days. Adding
triggers
with a conditional test to .deb scriptlets is rather easy.

Oh well, live and learn.

> But if they are not up to discussion of changing their
rpm  
> standards to
> be more in line with reality (I really mean no
disrespect...that is  
> just
> the honest way that part of LSB hits me) then I guess a
conversion  
> tool
> might be in line, but who is it going to help since it
would not be
> possible to install anything correctly?
>

As I hinted, extracting necessary (for real world
installers) can be  
extracted
dynamically at install time, not build time, thereby
reducing package  
size
and metadata bloat.

Simpler is always better.

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

> > But if they are not up to discussion of changing
their rpm
> > standards to
> > be more in line with reality (I really mean no
disrespect...that is
> > just
> > the honest way that part of LSB hits me) then I
guess a conversion
> > tool
> > might be in line, but who is it going to help
since it would not be
> > possible to install anything correctly?
> >
>
> As I hinted, extracting necessary (for real world
installers) can be
> extracted
> dynamically at install time, not build time, thereby
reducing package
> size
> and metadata bloat.
>
Most, but not all dependencies are autodetectable.  For
instance, in
perl I often use a design that provides for drop-in
dynamically loaded
modules.  Simple example would be our menu system that
allows a
developer to drop a module that provides a particular
interface in a
particular directory.  The directory is scanned modules are
loaded.
There is no general way for rpm to figure out that this
dependency
exists between the perl runtime dso's and the framework
they go with.

This is not an issue for dep sorting in this case because
its not an
install time dependency (though in the right context it
could be) but
its is dependency closure issue.   So, though automatically
detecting
deps at install time is a better approach it IMO cannot be
the only
approach.  In like vein manual deps should be avoided but
they can't
always be avoided.

> Simpler is always better.
Agreed...james
>
> 73 de Jeff
> _______________________________________________
> Rpm-devel mailing list
> Rpm-devellists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
>
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 24, 2006, at 10:12 AM, James Olin Oden wrote:

>> > But if they are not up to discussion of
changing their rpm
>> > standards to
>> > be more in line with reality (I really mean no
disrespect...that is
>> > just
>> > the honest way that part of LSB hits me) then
I guess a conversion
>> > tool
>> > might be in line, but who is it going to help
since it would not be
>> > possible to install anything correctly?
>> >
>>
>> As I hinted, extracting necessary (for real world
installers) can be
>> extracted
>> dynamically at install time, not build time,
thereby reducing package
>> size
>> and metadata bloat.
>>
> Most, but not all dependencies are autodetectable.  For
instance, in
> perl I often use a design that provides for drop-in
dynamically loaded
> modules.  Simple example would be our menu system that
allows a
> developer to drop a module that provides a particular
interface in a
> particular directory.  The directory is scanned modules
are loaded.
> There is no general way for rpm to figure out that this
dependency
> exists between the perl runtime dso's and the
framework they go with.
>

You are correct that interpreted languages like perl/python
can
include logic to lazily open DSO's (or other scripts) at
run-time,
and so the necessary prerequisites can never be detected
except by running the script exactly as intended.

That is an insoluble problem in my opinion.

What *IS* soluble, is running exactly the same automated
extractors
on the install machine, not the build machine.

E.g., similar to the previous --ldconfig example
     $ time ./rpmdeps --perl
     ...
     real    0m6.880s
     user    0m2.428s
     sys     0m0.424s
to extract the necesaary perl(foo) dependencies that are
actually
installed. As an important side effect, CPAN packages can be
installed using CPAN, not rpm, and rpm package dependencies
will be satisfied.

All this mechanism already exists since rpm-4.4.3 btw. I
just haven't
gotten around to lashing up the necessary opt-in/opt-out
macro
configgery to turn on the functionality.

> This is not an issue for dep sorting in this case
because its not an
> install time dependency (though in the right context it
could be) but
> its is dependency closure issue.   So, though
automatically detecting
> deps at install time is a better approach it IMO cannot
be the only
> approach.  In like vein manual deps should be avoided
but they can't
> always be avoided.
>

No said only, certainly not me. However ...
>> Simpler is always better.
> Agreed...james

... choice is not always simple.

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