Canonical is announcing the availability of PPA: a Launchpad-integrated free service which allows anyone to get 1 GB of space to upload whatever software they want. Launchpad will compile it automatically and will set up an apt repository with your package to anyone who wants to use it. Aditionally, PPAs offer bug reporting and translation services.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
"No, I get that. But what if you have both Gnome and KDE in a single backports repo, what if I only want to update KDE? Can I do a system upgrade without updating all packages available /backports? Or am I expected to update all available packages for the sake of consistency? I'm asking this as a legitimate question, because as I said I'm unfamiliar with your repo topology."
GNOME and KDE are disallowed as backports by policy, as being entirely too likely to cause problems. But I see your point. It's easy to enable and disable repos in MDV, and the recommended way to use /backports is to enable the repository when you want to install a specific app from it, install the app, and then disable it again. We don't recommend using it as a general-purpose repo that's enabled all the time.
There's a filter in rpmdrake (the software manager) that is supposed to allow you to install apps from /backports manually even when the repo is disabled, but I've seen a couple of reports that this isn't actually working as intended in 2008; but this mechanism is intended to cover exactly the scenario you outlined.
btw, I did a quick troll through SUSEForums to see if anyone was having trouble with the build service, and couldn't actually find anyone using it. I may have been looking in the wrong place, though.
Member since:2005-07-13
**GNOME and KDE are disallowed as backports by policy, as being entirely too likely to cause problems. But I see your point. It's easy to enable and disable repos in MDV, and the recommended way to use /backports is to enable the repository when you want to install a specific app from it, install the app, and then disable it again. We don't recommend using it as a general-purpose repo that's enabled all the time.***
Ok, now we're getting somewhere. So under your system, you can't provide "major" updates to core packages like KDE and GNOME due to the understandable potential for system disruption, despite the fact that pretty much every other distro can. And somehow your system of allowing users to temporarily enable a backports repo to install a package while then preventing them from receiving updated versions due to security/functionality patches is somehow better for system stability and upgradeability than having a system of automated "micro" repositories that allow the user to have granular control of selecting newer versions of packages while maintaining core package integrity *and* automatic update capability?
Dude, I've seen many of your posts here over time and you're generally very rational and well spoken in your opinions, even if I don't always agree with them. But I have to admit I'm really struggling to see why you're being so stubborn on this one. You've yet to provide a compelling reason as to why this is a bad move for Ubuntu, particularly in light of the fact it has worked well for openSUSE. If Mandriva is shunning automated build-systems for granular package management, that's absolutely your choice, and it's up to your users to decide if they're better served that way.
Like I said previously, give it some time. Maybe you will have the last laugh. But I still don't think you will.
***btw, I did a quick troll through SUSEForums to see if anyone was having trouble with the build service, and couldn't actually find anyone using it. I may have been looking in the wrong place, though.***
Possibly the wrong place, but it's scattered all over. There are posts for users regarding the KDE4 repos, or compiz, probably two of the most popular right now. Plus many users of 10.2/10.3 have already upgraded to current versions of KDE and Gnome through the build-service. The latest version of OOo2 is another popular update, and for added measure the build-service also provides snapshot builds of OOo2-unstable for testing. There are some users with Xorg 7.3, also available through the build-service. You could also stroll through the openSUSE wiki, and see the various 1-click install links, almost all of which rely on build service repos as well. Power users also acquire automatic updates of the KOTD (Kernel of the Day) through the repos, where is was previously provided through ftp download.
It's not black magic or blind luck, it's simply smart design on behalf of the developers that it works as well as it does. *buntu may have some bumps along the way initially, but I have no doubt it will become as powerful for them as it has for the openSUSE community.
Embrace the future. 
Member since:2006-02-02
btw, I did a quick troll through SUSEForums to see if anyone was having trouble with the build service, and couldn't actually find anyone using it. I may have been looking in the wrong place, though.
Anyone referencing "1-click install" or instructions from the openSuSE wiki is almost certainly using the build service. Technically, anyone who adds the official repositories is also using the build service.
There are still some external repos, but out of the 11 I have configured, 2 of them aren't on the build service (Packman and NVidia).
The fact that I can safely upgrade to the latest KDE and/or Gnome simply by adding the appropriate repo and running an update is a HUGE benefit of running openSuSE.
Member since:
2005-07-13
No, I get that. But what if you have both Gnome and KDE in a single backports repo, what if I only want to update KDE? Can I do a system upgrade without updating all packages available /backports? Or am I expected to update all available packages for the sake of consistency? I'm asking this as a legitimate question, because as I said I'm unfamiliar with your repo topology.
At any rate, I get your point, I simply don't agree with it. Dependency management need only be as fragile as the thought and planning that goes into it. We're in agreement that system stability is dependent upon supplementary packages being built against a consistent base. We're in disagreement as to how deeply entrenched those dependencies really need to be. If upgrading to a newer version of Amarok runs the risk of borking Gnome, then there's something very wrong with the package layout to begin with.
And obviously, if a newer version of Amarok requires a newer dependent package that could break the standard install of Gnome, then that is an entirely different case and in such a case that version shouldn't be presented as an upgrade possibility. That's why there exist packaging guidelines and standards.
A poorly managed build service in any sort of implementation will lead to all sorts of problems, but then so will sloppy package maintainers in a non-automated system. Nobody will argue that. But you still seem to be presenting theoretical arguments against something that is already beginning to prove its value and advantages. You're arguing worst-case scenario factors without giving due credit to the developers to manage the process correctly, the users to show common sense, and the community itself to make it successful. If the openSUSE devs and user community have found value in the build service, then it's likely that the Ubuntu community will as well. Particularly in comparison to the present system, which seems to consist of users self-packaging apps and hosting them on private ftp servers or posting them online.
Human error can naturally cause problems, but it's not like human error doesn't occur with manually packaged repositories either.