Re: AutoPortage

Hi,
    sorry for jumping into the discussion all in a sudden but I'm very much 
interested to an AutoPortage system:

Mike Hearn ha scritto:
> Well, the thing is, if you go and produce a big pile of autopackages
> yourself, you've just arrived back at the start - the very same
> problems that motivated its creation in the first place will reappear.
> What's more, by doing this you aren't working with the upstream
> projects themselves, you aren't addressing the maintainers concerns or
> teaching them how to keep the specfiles up to date or helping them
> improve their software.
> 
> 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. :)

This is my POV as an hobbyst OSS developer (I'm a developer of wxWidgets and a 
project admin of various other open source projects): AutoPackage would be a 
Great Thing, which would make Linux much easier to use, similar to Windows.
But creating autopackages is slow and you have to fight to do it, since in all 
open source projects you work in, you always find resistance against changes/new 
formats.

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.
The fact GCC is not the fastest compiler in the world really doesn't help.
The fact you should test other distro is even slower. The fact that in the end 
you're still far from sure that your autopackage will install fine on yet other 
distros you haven't tested doesn't help neither.

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.

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.)

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).

Still, they have the problems mentioned in this thread about centralized systems.

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.

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).

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.

Just my 2 cents,
Francesco


-- 







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