Re: AutoPortage

> I didn't really see this entry in the FAQ as applying, at first, since you
> were talking about a centralized package repository and I was talking about
> a ports/portage system for version tracking, compilation, and package
> production.

Maybe I don't understand your proposal, but to me a ports system for
building autopackages seems centralized - you or a few others would
produce a big pool of autopackages, independent from the upstream
developers.
> Before downloading
> them, I first checked the autopackage repository and did not see them
> listed.  So, we've got lag with autopackages, too..

I think it's a bad idea to read too much into the list we have on the
website. That was only ever really meant as a promotional tool, not
actually a market-type space where people go first when they want to
install things. The way autopackage was meant to be used was by going
to the softwares website and obtaining them from there - like what
Inkscape do.

> packages with even more lag.  Clearly, this is because the software
> maintainers don't supply their software using autopackage... But that's a
> reality.  An AutoPortage system would make this far easier for a maintainer
> to do or someone else, if the maintainer is unwilling.  New versions, in
> most cases, should be little more or no more than just pointing to the
> latest version of the source..

I think you underestimate the difficulty of correct packaging. This
kind of thing is exactly what I meant when I talked about obscure
bugs. If you just download a new tarball and run it through some
mechanical process, you'll introduce the same bugs that Debian, Fedora
etc do today.

What's more, for best compatibility you often need to patch the
software itself, eg, to make some things optional at runtime instead
of at compile time. We offer the tools to make this easy but somebody
still has to do the patch, contribute it upstream, get it integrated
etc.

> This is true.  But it beats not having the package at all.  If the
> maintainer won't do it then that doesn't mean nobody should.

Anybody can build a package and donate it to the upstream project,
that's how the Inkscape autopackage got started. Eventually if the
upstream project sees real benefits, they'll take it on board just
like a regular patch. And by becoming a part of that upstream project
you'll actually understand what it is you're doing.

>  Perhaps you've all been thinking user's should just google
> to find individual project sites, download and use..  There's nothing wrong
> with that, but a central search, review and at least user generating
> documentation would make it much easier on users.

Yes that's exactly how autopackage was always meant to be used. I
thought this was clear from the various screeds on the website but I
guess not. We aren't going to beat Google at search anytime soon, and
if you have search you can find reviews, discussion sites, wikis etc
very easily.

> I think the only way to combat this is to show them something better.
> Autopackage is technical capable of being that something better but I am
> getting the sense you all might be similarly unwilling to accept change
> where it is needed.  It would great if every software developer produced and
> supported autopackages but the fact is, they don't.  Theory is not meeting
> reality and another measure is needed, if at least a temporary measure.
> Only when autopackages are available to the point of a certain critical mass
> will developers, generally, begin to accept and adopt it.

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.

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