Re: AutoPortage

On Tue, Dec 30, 2008 at 1:05 AM, Francesco Montorsi
<[email protected]> wrote:
>
> Mike Hearn ha scritto:
>>
>> For this reason, I've never been a fan of this type of proposal (there
>> have been many over the years) - it's mixing up the means and the end.
>> There's no point to autopackage if you don't end up with decentralized
>> distribution, no matter how many of them exist. Whilst doing it all
>> yourself sounds easier than working with each project individually,
>> ultimately it's self defeating.
>
> I agree with you Mike. I also agree with Matthew. :)
>
> Creating autopackages is slow, at least for me, because you usually have to
> recompile all the statically linked stuff (in my case it's usually wx) with
> settings different from the usual ones, resolve eventually linker errors
> (typically related to GNU libc stuff), repeat compiling/linking until
> everything is fixed, test the package with different distro, eventually fix
> other errors, finally upload it.

Yes. This is true because we have no stable platform to develop in the
linux world. You never know how the target system will look like which
is why you have to test and test and test.

On other systems, you still have to test, but you will focus on
testing your application code, not how it will work with some weird
patching of the distro or whether lib A is called foo or bar on the
users system.

> On Windows the situation is much different; once you've written your NSIS or
> similar script, you're almost done and the final result you are sure at
> 99.9% is compatible with all main window versions, which are far fewer than
> linux variants btw.

Yes, because microsoft actually has compatibility as a top level
agenda item. They spend unhealthy amount of work and money on making
sure that apps that run on windows X will continue to run on windows
X+1. In fact, I've read about a guy who would actually add application
specific workarounds in the windows code to make sure that certain
apps that used non-documented api's or relied on buggy behavior in
older windows versions.

I'm not gonna argue on whether this is a good or bad decision by
microsoft. But what you get in the end is an almost guaranteed binary
compatibility which is something that third party vendors like.

And by the way, yes there are fewer windows versions but they differ
way more than the linux distros.

We have developed the tools to make binary portability easier on
linux, but we never managed to create a silver bullet. APbuild and
related tools is a good step on the way, but it doesn't solve all
problems.

> I've introduced autopackage and written scripts for it for some projects but
> in the end no other developers except me got "excited" by it and helped
> maintaining and producing updated autopackages.
> The final result is that I am the lone maintainer of the autopackages and
> since I'm lazy they're typically not up2date with latest releases of their
> relative software packages. (That's probably also because I like to program,
> not to package. I don't want to be annoyed by packaging issues and like me,
> the 99% of other developers don't care and do not want to care of those
> details, too.)

This is the mentality that has to change. Installation is one part of
the user experience of using your application, in fact one can argue
that it is one of the most important one since it's the first
impression of it. A failed installation means that the user cannot use
your program. A hard installation will give the user a bad impression
of your program.

A piece of software is so much more than the lines of code that makes
up the final executable.

(I do understand your point though. I'm a programmer myself and
typically enjoy writing code much more than anything else in a
software project. What drives me to do the boring parts is that I
think it will benefit the end user in that (s)he will have a better
experience using my software)

> Then I look at the centralized packaging systems like Debian, Ubuntu, etc.
> From what I've seen, they have a well-estabilished system
> (http://buildd.debian.org/) which does the 99% of the work for them, once
> created the initial scripts. (Please correct me if I'm wrong here).

Think this is true.

> I think an AutoPortage system could join the advantages of a de-centralized
> system with those of a centralized one: you submit a link to the AutoPortage
> of your application sources, and of your .apspec; it automatically builds
> everything and maybe runs some automated test. Then you tell Autoportage
> where the package should be uploaded, i.e. its definitive place: the project
> website. Then just update your website with the link of the new package.

Wait a minute. this sounds like you are only going to create an online
build box ?

If the apspec is already maintained by upstream, what's the difference
then by pointing some tool to an URL and writing "makepackage" in
bash?

> To the final user it looks like a de-centralized system, but the packager
> needs only 5 minutes to create the autopackage (possibly a login in
> AutoPortage and a click on a button in a web app).

Again, once the hard stuff is done, building an autopackage is an
automated procedure:
The hard stuff:
 * Writing/maintaining the apspec
 * Dependency audit of the software - remove unneeded ones, make some
runtime detectable etc.
 * Add binary relocation support
 * Make sure it compiles with apbuild
 * Compile any statically linked libs with apbuild

I don't see anywhere in your proposal how this is going to be solved
in AutoPortage

> Ok, I know there are lots of technical difficulties possibly hiding in this
> simplified description. However I think that the current path of AutoPackage
> isn't bright and that when you have "nothing to loose" (which could NOT be
> the case actually - I don't have stats for autopackages, I judged this from
> the fact I almost never see autopackage downloads for the software I'm
> interested and from the low activity of this mailing list) it would be
> better to try new ways, new ideas, instead of letting the project slowly die
> and finally be forgotten.

Here you have a very valid point. It's weird for me and Mike to come
in and shoot down your suggestion when we don't really contribute much
to autopackage anymore. (please don't take it as that - we're just
trying to save you from doing some of the mistakes that we've seen and
done ourself)

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]