On Sun, Jun 22, 2008 at 11:02 AM, Denis Washington <dwashington@gmx.net> wrote:
> I don't think this is a corner case at all. For one thing, propietary
> applications might just don't play a role _because_ there is no really
> good distribution method for them - the typical chicken-and-egg problem.
> (I'm not saying this is the only reason, but an important one.) We're
> just not giving them an easy method of cross-distro integration. I think
> providing this is important.

Sure, and that's why I support the LSB.
Has everybody else given up on it?
- Dan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, Jun 22, 2008 at 11:02 AM, Denis Washington <dwashington@gmx.net> wrote:
> I don't think this is a corner case at all. For one thing, propietary
> applications might just don't play a role _because_ there is no really
> good distribution method for them - the typical chicken-and-egg problem.
> (I'm not saying this is the only reason, but an important one.) We're
> just not giving them an easy method of cross-distro integration. I think
> providing this is important.

Sure, and that's why I support the LSB.
Has everybody else given up on it?
- Dan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote:
> The distro model is nice (and arguably better than the LSB Package API)
> if the packages you like to have are in the repos in sufficiently new
> versions. But if you need to go past that (bleeding edge versions, not
> widely spread apps), things get more difficult currently. Especially
> propietary applications just cannot be distributed by the distros
> directly.

Right. These packages are compiled against system versions of libraries.
Do we choose the F9 or rawhide version of xulrunner to link against?
There's substantial API and ABI changes between distro versions for the
majority of shared libraries.

> I don't think this is a corner case at all. For one thing, propietary
> applications might just don't play a role _because_ there is no really
> good distribution method for them - the typical chicken-and-egg problem.

Incorrect. Most closed-source applications I have to use are installed
with an installer binary or script, which just smatters files on the
hard drive in /opt. There's just no need to register these with the
native system package manager as there are no updates repositories nor
dependency tracking required.

> Second, this way of distribution will help open-source projects as well.
> It would make it really easy for them to distribute bleeding-edge
> versions of there apps that integrate well into the packaging system
> without having to package for each and every package manager.

Who supports these bleeding edge packages? Where do the users get
security updates from? What if the library it's compiled against also
changes to a bleeding edge version too? This is not a standard use case,
unless you want a system like gentoo where you compile from source.

> It will
> also help those projects which are not widely used enough to be in
> distro repos, as they can more easily release binary distributions
> without having to depend on getting packaged by the distros.

Bad argument - see the PackageKit archives for details why this is a
really, really, bad idea.

> I really
> believe this decentralism would be very nice to have, especially in
> something as naturally decentralized as the open source community.

Err, open source communities are not decentralised. They are _more_
centralised than closed source software. I currently use one vendor for
my new software, my updates and also all the metadata and translations.
I use the same vendor for talking to users on forums and developers on
mailing lists and use the same channel for pastebin and collaborative
editing. My vendor is Fedora.

Calling an open source community decentralised is a very naive statement
in my honest opinion.

Richard.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes <hughsient@gmail.com> wrote:


On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote:

> The distro model is nice (and arguably better than the LSB Package API)

> if the packages you like to have are in the repos in sufficiently new

> versions. But if you need to go past that (bleeding edge versions, not

> widely spread apps), things get more difficult currently. Especially

> propietary applications just cannot be distributed by the distros

> directly.



Right. These packages are compiled against system versions of libraries.

Do we choose the F9 or rawhide version of xulrunner to link against?

There's substantial API and ABI changes between distro versions for the

majority of shared libraries.



> I don't think this is a corner case at all. For one thing, propietary

> applications might just don't play a role _because_ there is no really

> good distribution method for them - the typical chicken-and-egg problem.



Incorrect. Most closed-source applications I have to use are installed

with an installer binary or script, which just smatters files on the

hard drive in /opt. There's just no need to register these with the

native system package manager as there are no updates repositories nor

dependency tracking required.>
You you like an opinion on this, well, that it is mine. For example, look ad Oracle Client 11g
application : it. as released with a tarball or so, have on it:



- a full stack of perl
- a full stack of shared library : glibc in primisis.

So what have to do un poor packager manager with this ? Disable the deps and hope the best. Other, as MQ client, are released with RPM : with deps disabled anyway. But not all


are equal : for example websphere. Sure it is tricky to package it but almost don't force me to disable the deps: I DON'T WANT DISABLE THE DEPS.

IMHO, YMMV as usual



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sat, 2008-06-21 at 14:57 +0200, Nicolas Mailhot wrote:

> Le samedi 21 juin 2008 à 13:20 +0200, Yaakov Nemoy a écrit :
>
> > How is this different than PackageKit?
>
> It would make possible for ISVs to create packages in a non-native
> packaging format, so they don't have to care about the format each
> distro uses, or about understanding each distro dependency checks, or
> generally speaking wasting time and money on integration and QA.
>
My general feeling, having spoken to lots of ISVs, is that they don't
actually _want_ this.

In order to support their customers, they're well aware that they have
to target particular distributions and versions - and they're quite
happy working and certifying particular vendors individually.

Scott
--
Scott James Remnant
scott@canonical.com

On Mon, 2008-06-23 at 00:08 +0200, devzero2000 wrote:
>
>
>
> On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes
> <hughsient@gmail.com> wrote:
> On Sun, 2008-06-22 at 20:02 +0200, Denis Washington
> wrote:
> > The distro model is nice (and arguably better than
> the LSB Package API)
> > if the packages you like to have are in the repos in
> sufficiently new
> > versions. But if you need to go past that (bleeding
> edge versions, not
> > widely spread apps), things get more difficult
> currently. Especially
> > propietary applications just cannot be distributed
> by the distros
> > directly.
>
>
> Right. These packages are compiled against system
> versions of libraries.
> Do we choose the F9 or rawhide version of xulrunner to
> link against?
> There's substantial API and ABI changes between distro
> versions for the
> majority of shared libraries.
>
> > I don't think this is a corner case at all. For one
> thing, propietary
> > applications might just don't play a role _because_
> there is no really
> > good distribution method for them - the typical
> chicken-and-egg problem.
>
>
> Incorrect. Most closed-source applications I have to
> use are installed
> with an installer binary or script, which just
> smatters files on the
> hard drive in /opt. There's just no need to register
> these with the
> native system package manager as there are no updates
> repositories nor
> dependency tracking required.>

Well, if there is no update tracking, there is naturally no gain in
having the application registered with the package (well, perhaps except
the user being able to uninstall the application with their package
manager and ISVs not having to provide an explicit uninstaller). But a
way of tracking updates _is_ planned, even if it isn't in the spec right
now. This is especially crucial because LSB applications may not depend
on anything else but the LSB itself, that is, they need to care a lot of
libraries around. Without update integration, this would certainly suck.
But it should be possible in a "final" LSB Package API by all means.

> You you like an opinion on this, well, that it is mine. For
> example, look ad Oracle Client 11g
> application : it. as released with a tarball or so, have on
> it:
>
> - a full stack of perl
> - a full stack of shared library : glibc in primisis.

Wow, that's taking it to the extreme. Both glibc and perl are in the LSB
afaik.

> So what have to do un poor packager manager with this ?
> Disable the deps and hope the best. Other, as MQ client, are
> released with RPM : with deps disabled anyway. But not all
> are equal : for example websphere. Sure it is tricky to
> package it but almost don't force me to disable the deps: I
> DON'T WANT DISABLE THE DEPS.

Well, the problem with arbitrary dependencies is that you can't
guarantee that every distro has them, or has them in the correct
version. But as the many important libraries are in the LSB and thus are
used system-wide, the problem of having to package the remaing ones with
the application is not that big IMHO, especially if there is integration
in the packaging system's update tracking.

> IMHO, YMMV as usual

Sure, same for my reply naturally.

Regards,
Denis

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

sön 2008-06-22 klockan 11:41 -0800 skrev Jeff Spaleta:

> Stand up a usage case which benefits open source
> software and wok through that usage case.

Then how about this use case:

To simplify the uninstallation of installed proprietary packages.

I guess a way to do that would be to add support for uninstalling
autopackage packages using the PackageKit interfaces.

/abo

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

mån 2008-06-23 klockan 20:07 +0200 skrev Alexander Boström:

> Then how about this use case:
>
> To simplify the uninstallation of installed proprietary packages.

That's not a use case but never mind.

/abo

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, Jun 23, 2008 at 10:07 AM, Alexander Boström <abo@kth.se> wrote:
> Then how about this use case:
>
> To simplify the uninstallation of installed proprietary packages.

I think you missed my point entirely about not standing up proprietary
packages as the primary reason. Hopefully the original poster got my
point.

> I guess a way to do that would be to add support for uninstalling
> autopackage packages using the PackageKit interfaces.


I'm still waiting for someone to give me a comparison between the
LSB/Berlin API concept and what autopackage currently does. Is there
really a need for the LSB/Berlin API? Does it really do more than what
the autopackage roadmap encompasses? Just from a motivations point
of view, it seems to me that autopackage is meant to solve exactly the
same problem as the LSB/Berlin API. And if that is the case, and its
only implementation details that are different, then I think its
probably appropriate for the LSB/Berlin API supporters to do a
compare/constrast against the more mature autopackage concept so we
can get a better understanding of the detailed differences. Sadly,
such a comparison would need to use very small words, if I am to be
part of the target audience.

-jef"My comments should not be construed as support for autopackage."spaleta

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

mån 2008-06-23 klockan 10:42 -0800 skrev Jeff Spaleta:
> On Mon, Jun 23, 2008 at 10:07 AM, Alexander Boström <abo@kth.se> wrote:
> > Then how about this use case:
> >
> > To simplify the uninstallation of installed proprietary packages.
>
> I think you missed my point entirely about not standing up proprietary
> packages as the primary reason. Hopefully the original poster got my
> point.

Of course I got the point! But to help get rid of proprietary software,
how could that be wrong?

Answer: By helping those who installed it in the first place.

It's not wrong, it's just not something I expect anyone around here will
care much about. But the LSB devs might.

/abo

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list