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

Peter Dolding oiaohm at gmail.com
Sat Dec 27 23:21:23 PST 2008


On Sun, Dec 28, 2008 at 4:24 PM, Dan Kegel <dank at kegel.com> wrote:

> On Sat, Dec 27, 2008 at 10:05 PM, Peter Dolding <oiaohm at gmail.com> wrote:
> >> I don't consider Berlin part of the mainline packaging system.
> >
> > Remember neither is your solution Dan.
>
> You're saying that making incremental improvements to
> the mainline packaging system already used by every
> major distribution -- improvements already being undertaken
> by the distros themselves -- isn't mainline?


No because those alterations don't have to be to the core criteria that were
set down when LSB was formed.   Mainline of LSB follows the core criteria
that was set down when it was formed.   If following the core criteria
happens to line up with what distributions are doing so be it.  If not
solution has to be created to either expand what the distributions are doing
to get to core criteria or replacement used.  Berlin in case of replacement
used.   Distribution netual solution that should not offend slax gentoo and
other edge distributions too much hopefully pulling some of the break away
distributions back in to get broader debates on the future of linux.
Becides "shipping everywhere" is not just about Linux Distributions pulling
solaris and bsd people in here would also broaden debates.

Remember just because a distribution is major today does not mean they will
still be major in 5 years time.   All selections by LSB have to try to
remain future safe.  Yes core criteria.  Best way to be future safe is cover
everyone so no matter who wins you were backing them.   Who would have
though 5 years ago Ubuntu would have been a major distribution or that
Mandrivia would be pushed to edge now.

>
> >  Difference here
> > http://www.linuxfoundation.org/en/ProjectPlan40 read roadmap.  Berlin is
> on
> > it for next release.   Yours is not dan.  You have to make a valid case
> to
> > push it off the roadmap and replace it.
>
> I'm not proposing anything with respect to Berlin.  If somebody
> implements it, fine.  I don't really care.  I just don't think it's a
> good use of resources.    It solves a problem that isn't there, I think.
> From what I can tell, it was invented because certain high
> value ISVs like using things like Installshield to do their
> installers, and they don't want to change.  Somehow it
> was decided that informing the package manager about
> what installers like that do will help with something.
> I suppose it would make uninstalling easier, but I don't
> see that as a really important goal.
>

Sorry you are proposing is in conflit with Berlin.  Proposing something that
Berlin exists to allow happen.   Using different repository formats.
Berlin allows that by ISV providing there own front end for there choosen
repository format.  If you go back through LSB packaging mailing list
history there has been dispute after dispute about what repository format
should be used by LSB.   Yes LSB simply washing hands of the repository
issue due to not being able to get common agreement.  So any repoistory
issue will have to make Slax Gentoo Debian Redhat at a min happy.   Yes Slax
and Gentoo are outside LSB these days.

Berlin is basically we open a door you do what you like with it.   Berlin
invent reasons have nothing to do with installshield.   Berlin is also about
addressing RPM security issues of its installation scripts.

This is your problem you are failing to see what Berlin has fixed.   Berlin
was always planed to be expanded in time to include an update system.
Berlin on the table to unlock the market and let market forces decide long
term what kind of packaging should be intergrated into LSB.   So you do have
to come up with a good solution or it simply thrown over to market forces
for your solution to compete in live or die.

>
> > This is why you are getting walled Dan by me.   Your solution needs lots
> of
> > work to get upto a equal solution to Berlin.  What is being put forward
> is
> > missing key sections for me to go ok good enough passes the needed
> > criteria.  Now of course I would love better than Berlin.   Personally
> think
> > Berlin is going to be a mantaince nightmare due to using installers and
> the
> > like to update itself.   Another reason why it was delayed for 1 more
> > release.   Basically the clock is ticking for a solution the shipping
> > everywhere criteria to be developed without it we all have to live with
> > Berlin.
>
> No, Berlin is sitting still because it doesn't solve any known problem.
> I can't figure out why it's listed as high priority on the roadmap.
> Ian was right in his summary of the problems, but I don't think
> that the Berlin API as proposed solves the problems he talked about.
>

You miss the most logical answer.   Simple fact Berlin API strawman we could
get common agreement on there was a broader API that covered all of Ian
points but its cut back to Berlin.  Berlin does allow one of the criteria
set down when LSB was formed to be completed.   It is closer to the criteria
of  "shipping everywhere" than current interim solution.  It does address
secuirty issues messy but does addrees them.   It does address runtime
issues ok messy but does address them.  Ok leave updating in the crapper.
Yes funny enough updating is one of the things that never made it into LSB
core criteria.  Yes Berlin is the first step to a final solution until it
gets to the final solution is going to be messy.

Missing addressing issues is a really bad thing to be doing.

Hopefully someone can create a solution that meets LSB core criteria and is
more friendly than Berlin.   Must be secure is one of the old common
criteria issues.

You need to be covering how what you are doing is about getting to the us
closer to the core criteria of LSB to push Berlin off roadmap.  Proposing
feature that Berlin allows and Berlin is on roadmap with nothing going to
the core criteria of course you would hit a problem.

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


More information about the packaging mailing list