Auto Package

[Corey Burger]

Probably for me the biggest reason not to allow autopackage has to do
with trust and security.

Installing random stuff off the internet is described as a-bad-thing.
However, Windows machines do it all the time, and observe the end
result.

By contrast stuff that is a repository has at least gone by one
person, who probably has the technical knowledge to look at it and see
if it is a rootkit.

The bigger problem behind this however is users. User cannot tell the
difference between a rootkit and not. This is demonstrable. Again
observe windows. Thus users should never every, IMHO, get into the
idea that software comes off the internet. If we break that mental
connection, we will have gone a long way to combatting malware.

Corey


On Tue, 29 Mar 2005 11:33:16 -0800, Matt Zimmerman <mdz at ubuntu.com> wrote:
> On Tue, Mar 29, 2005 at 06:50:54PM +0100, Mike Hearn wrote:
> 
> > On Tue, 29 Mar 2005 09:24:50 -0800, Matt Zimmerman wrote:
> > > Hoary has been in a state of freeze for months now.  The fact that these
> > > applications are held at older versions is intentional and beneficial for
> > > stabilization.
> >
> > Yes, I understand that. But stabilisation is not solving a users problem,
> > it's solving a distribution development problem.
> 
> I entirely disagree; the reason we provide stable releases is because users
> want them.  Distribution developers generally follow the leading edge.
> 
> > > If an application is simple enough to be packaged by autopackage, then
> > > it is scarcely more work to package it properly, and this provides a
> > > base for future work on the package.
> >
> > Well, ignoring whether a deb is more "proper" than anything else
> 
> Consider that Ubuntu ships pretty much the same software packages as
> everyone else.  The entirety of what distinguishes us from other
> distributions is the work that we put into our packages, enabling them to
> work well as a complete system.
> 
> > , the trick is *will* it be packaged? Developers can produce autopackages
> > that work for anybody, but the existence of a Debian/Ubuntu package
> > depends on finding a Debian/Ubuntu user who knows how to package software,
> > wants to and who also has access rights to do so.
> 
> The issues you raise are:
> 
> - .deb packaging is too complicated.  The solution to this is to make
>   .deb packaging easier, not to replace a mature and robust packaging system
>   with something more like autopackage.
> 
> - There is sometimes a shortage of motivation to create packages.  This is
>   not a technical problem, and is shared equally by any packaging solution.
> 
> - Access rights don't really enter into the equation.  Packages can be
>   created by anyone, we have a review process to incorporate new packages
>   into the distribution, we import packages from many existing repositories,
>   etc.  There are many packages in Ubuntu which were created by people
>   without any privileges within Debian or Ubuntu.-
> 
>   Additionally, it is a simple matter to get involved with the MOTU team and
>   upload packages directly if one is motivated to do so.
> 
> > Random example: glom doesn't seem to have any package, but has existed for
> > years.
> 
> It doesn't provide any packaging metadata, either.  No debian/, no .spec, no
> .package.
> 
> > > That may be the only way that you can see, but there are many ways, and
> > > we intend to explore them.  We are well aware of the potential problems
> > > that you describe.
> >
> > Care to share what these ways are? I'm always open to new ideas.
> 
> The basic desire here is for new pieces of software, and new releases of
> software, to be integrated more quickly.  Things which promote this are:
> 
> - Simplification of the packaging process
> - Automation of the packaging update process where possible (basic tools
>   have existed for a long time)
> - Improved source control
> 
> --
>  - mdz
> 
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>