[icebraining]

So, how does the fact that any person or company can host their own packages or even full repositories that can be added with a single click¹ and are not dependent on hierarchical organizations fit in that?

GNU/Linux distros, at least APT based ones, are perfectly distributed if the person wants to.

¹ If you have apt-url installed, which Ubuntu has by default

[moe]

I agree that distributed repositories are the way forward.

The only thing holding that back is the atrocious user-interface. Debian urgently needs to fix that and push their apt-infrastructure out of the 1990s.

In short: /etc/apt/sources.list must die.

This is how it must work:

   apt-get install https://foobar.com/debian/squeeze/widget-1.0

A package installed like that must add itself automatically to a proverbial sources.list for future updates. Don't bother me with the housekeeping.

Then add central indexing ('apt-get install widget' is nicer), a web-of-trust ("1234 users have installed packages by this author"), package-signing looks about alright already (except: no, don't make me run gpg).

This can (will and does) co-exist happily alongside the centralized repositories. Someone just needs to implement it and push it through the glacial Debian processes.

And while we're at it, there's no reason 'apt-get install github://foobar' can't be made work.

tldr; apt needs to absorb homebrew.

[icebraining]

But what's the problem with sources.list, as long as the user doesn't have to manage or even know that it exists?

Provide a .deb from your website, use the install script to add your repository to the sources.list. There, the user doesn't have to know or care about that file. And this is all possible - no, easy - to do right now.

This is how it must work:

I disagree, having to run apt-get is too cumbersome to a regular user. But a better way already exists in the form of apt-url. Click a link, have the package downloaded and installed automatically.

This can (will and does) co-exist happily alongside the centralized repositories. Someone just needs to implement it and push it through the glacial Debian processes.

But my point is that most of the infrastructure (support for multiple repositories, one-click installation of third-party packages) already exists. That's why I don't agree that this is the problem with Linux.

And while we're at it, there's no reason 'apt-get install github://foobar' can't be made work.

I don't see how - there's no standard on GH projects for installation; some projects are installed by simple make/make install, others with easy_install/gems/npm, etc.

[moe]

But what's the problem with sources.list, as long as the user doesn't have to manage or even know that it exists?

You are right. My point was that I (the user) shouldn't need to know that a file by this name exists. Of course debian is free to maintain the bookkeeping in any way appropriate.

I don't see how - there's no standard on GH projects for installation; some projects are installed by simple make/make install, others with easy_install/gems/npm, etc.

People would check-in either the deb or the debian/ meta-files. The latter would be preferable, but the deb package-building process needs to be simplified for developers to consider participating.

The current deb building procedure is a trainwreck, which is in fact a related problem. Homebrew recipes and gentoo ebuilds are trivial in comparison, there's no reason the deb process needs to be as convoluted as it is.

[morsch]

You are broadly describing PPAs. Adding a package from a PPA is a three-line (easily scriptable) process: add-apt-repository <url|ppa-name>, apt-get update, apt-get install <package>. Obviously, that doesn't just work for PPAs, but for all apt repositories.

Launchpad does some central indexing ("other versions of this package") for PPAs, but I don't think it's accessible via command line. There is no indication how popular a PPA is, but PPAs are linked to admin user accounts which might help. Packages are signed and the key is auto-imported. Packages co-exist alongside packages from the repos, you can easily switch between different provided versions.

Installing a plain deb is much easier still, but you don't get upgrades (unless the repository is auto-added during install) or signing.

[moe]

You are broadly describing PPAs.

Yes, indeed I am. The point where PPAs fall short is that the user still needs to add a repository when all he wants is to install a package.

I maintain `apt-get install https://foobar.com/pkg` is where it's at. Feel free to query me all you want ("really add this untrusted repo?", "fetch updates from there?", "trust this key?" etc.), but by all means make it a one-liner. Not three, not two, one.

And have proper procedures for all the little corner cases where PPAs fall down. I.e. when the repo goes away or changes URL, when the signing key changes, etc.

It's a matter of polish. Non-technical users need that polish. And technical users like it, too.

[morsch]

Like I said, the three line process is trivially scriptable, so you could make a one-liner script that works like you describe, ie. install https://foobar.com/repositoryX pkg or install ppa:xorg-edgers/ppa nvidia-graphics-drivers. I suppose you could combine the two parameters into a single URL to make it more familiar for users.

I don't see why it'd have to be integrated into apt-get itself, which does other things. The next step would be to create this a GUI process and to integrate it into apt-url, to make it easy to install stuff from the web. Of course making it easier to install stuff from untrusted sources also makes it easier for users to install malware, which I recon is why they haven't made it this easy yet.

If you want to have the ability to pull updates, you need some location to query for them, and that location is the repository. Even if it's just for a single package. If you want to install a single package without updates, there's deb files.

[moe]

I don't see why it'd have to be integrated into apt-get itself

That's exactly what I'm talking about. To give just one of many reasons: Because currently 'apt-get update' fails hard as soon as a PPA repo disappears. These corner cases must not exist. This is fundamental infrastructure, save the "easy workarounds" for higher levels.

Apt has been "almost there" for about 10 years now. But "almost" is not good enough - neither for desktop-users, nor for professional deployments with puppet/chef that have to fight the same and similar issues (e.g. idiotic license seed files, key conflicts, daemons auto-starting after installation, unreliable exit codes/error reporting, insufficient logging, insufficient hooks to override defaults).

We're in a state of inertia where everyone is so used to working around ever the same bugs that they're not even recognized as bugs anymore. I should absolutely not need a ~80 line puppet manifest or chef cookbook to make apt behave right. Desktop users should absolutely not have to find a bash-script (no matter how small) to be able to seamlessly install third party software.

If you want to have the ability to pull updates, you need some location to query for them, and that location is the repository. Even if it's just for a single package. If you want to install a single package without updates, there's deb files.

I'll quote pg on this: If you think something is supposed to hurt then you're probably doing it wrong.

Apt is a beautiful concept. Sadly the implementation stopped evolving shortly after becoming "good enough" rather than proceeding to "the best we can possibly make it".

[morsch]

Because currently 'apt-get update' fails hard as soon as a PPA repo disappears.

No, it doesn't:

  W: Failed to fetch http://repository.spotify.com/fake-
  url-to-fool-apt/dists/stable/non-free/binary
  i386/Packages  404  Not Found

  E: Some index files failed to download. They have been
  ignored, or old ones used instead.

All the other repositories are refreshed as usual. Again, apt-get and the rest of the underlying infrastructure is not the problem. I agree that users should not have to find a script, I'm just saying that's a reasonable way to solve the problem. The script should be part of the distribution, just like add-apt-repository, another script, already is.

(That said, I can agree that integrating this functionality into apt offers a chance of deeper integration in the future. And while it's not the Unix way, it may be that the Unix way has stood in the way of an ideal Unix desktop experience for some time now.)

[unlogic]

> tldr; apt needs to absorb homebrew.

An excellent package manager that exists for 14 years already is being told to mimicry a primarily inferior set of cruthes? The world has definitely gone mad.