[packaging] Meeting next week to discuss trusted third-party repositories

[Peter Dolding]

On Sun, Dec 28, 2008 at 2:53 AM, Dan Kegel <dank at kegel.com> wrote:

> On Sat, Dec 27, 2008 at 2:16 AM, Tortanick <tortanick at googlemail.com>
> wrote:
> >> Do you think it would make sense to have separate lists,
> >> one for discussing "standard model" solutions, i.e. those that
> >> build on current mainline techniques (rpm, deb, lsb),
> >> and another for "alternative" solutions, i.e. those that reject
> >> the idea of trusting Linux distributions and/or the LSB?
> >> Or is that too much fragmentation?
> >
> > Having seperate threads seems to be effective enough :)
>
> I'm not so sure.
> Every time I try to get discussion going about mainline
> stuff, various anti-mainline people jump into the thread,
> with mixed results.


Problem here.  Standard specifications states a lot of things that are not
used.

Your define of mainline sorry is not correct.   I have asked many times what
is planed or ideas to deal with runtime issues to be put on table.
Installation and runtime issues are interlinked issues.   Berlin one of the
few things that has passed a vote yet not implemented for installing
applications included at least some basic support for using Distribution
installed run-times and for installer to install outside runtimes if
required.   Berlin basically does not give a stuff about trusted
repositories leaves it to the ISV to design whatever repository system they
like.

Major issue here adding a repoistory format means displacing Berlin
agreement.  So should be designed to replace Berlin need to cover its
features.  Failing to do so is not answering problem.   Berlin also is
because ISV's have asked for configure on install.

List of key features that make up the Berlin agreement.

1) Means to use non LSB runtimes and smartly install any of those runtimes
ie if distribution already has it no need to install it.  If distribution
does not have it install it or if the distribution version is broken install
it.

2) Configure on install.

3) Means to use any repoistory format due to none of the parties at the
berlin meeting able to agree on a common repoistory format.  So yes fighting
putting forward third-pary repositories should be expected.  Yes messy each
application provides its own update system.

4) The means to install on any distribution.  Since installers are
executables if they don't detect the berlin api they can inform user and
help user install berlin api for there distribution or install in the users
home directory.

Problem here is more not understanding future mainline requirements what has
basically be voted on to be mainline future requirements.  Berlin is high
list to be include in next LSB standard because it matches the future
requirments.

Now I have at long last worked out your problem.  You are reading the
current LSB 4.0 and before.  Not the roadmaps of planed features.    Your
idea is a pure overlap with Berlin with more limitations.

So when you say mainline sorry LSB 4.1 standard already has requirments
failure to meet is why you get ripped by me.  One fo LSB 4.1 requires is a
option to install everywhere.  I am after talk about features that match the
requirements to be in LSB 4.1.   Not features that will just be kicked out
because they are not upto the requirements.   Idea that is fragmenation
causing the issue is wrong.

The issue is a pack of people here are off topic badly.   Looking backwards
at existing standards completely forgetting that future requirements of LSB
are already layed down.

Dan can you truthly say that what you have put forward is compadible with
the 4 key points of berlin packaging agreement.   You have been so far
always in breach of number 1 and 4.  Yes I am in breach of 3 from time to
time basically testing if it still current.

Problem you have here I am defending the mainline requirements.   Berlin
will stay in place unless something truly better is put forward.

>
>
> On the bright side, private emails I've gotten in response to
> my post give me hope that the mainline techniques are
> improving.  In particular, I've heard about work
> being done on package validation (checking that a package
> follows various rules before allowing it to be installed)
> and on reducing the power of package control scripts.
> I hope those folks post here soon.
>

Fixing up control scripts would be inside secuirty that require doing.   I
am not going to respond nasty unless method is flawed.   So post them.

Peter Dolding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/packaging/attachments/20081228/06299280/attachment.htm