Ubuntu
software-properties package

add-apt-repository should allow version specification or offer next highest repo version if repo for running version is not found

Bug #502454 reported by Eric Appleman
48
This bug affects 9 people
Affects Status Importance Assigned to Milestone
software-properties (Ubuntu)
Confirmed
Wishlist
Unassigned
Declined for Maverick by Sebastien Bacher

Bug Description

Let's say I'm running the Lucid alphas but the PPA only offers up to Karmic.

add-apt-repository does not let me specify Karmic and if I use the command as designed, a deb/deb-src line for a non-existent Lucid repo is added to my source list rather than the desired Karmic repo.

In order to get the Karmic repo, I have to add the deb/deb-src manually or through the GUI without automagically getting the necessary GPG keys.

Furthermore, add-apt-repo should automatically offer then next highest repo version if a repo for the running version is not present. If a Lucid repo is not present for my Lucid install, offer the Karmic repo instead.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: b8398b21075a3a8723b2ba20478c4f9e
CheckboxSystem: 703a6ca1eefae989daaf40c6bb6aa94a
Date: Sat Jan 2 17:45:19 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20091218.1)
Package: software-properties-gtk 0.75.6
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-9.13-genusername
SourcePackage: software-properties
Tags: lucid
Uname: Linux 2.6.32-9-generic i686

See original description
Revision history for this message
Eric Appleman (erappleman) wrote :
Eric Appleman (erappleman)
summary: - add-apt-repository assumes running version is same as highest version
- offered by PPA
+ add-apt-repository should assume highest version offered by PPA is less
+ than or equal to running version
summary: - add-apt-repository should assume highest version offered by PPA is less
- than or equal to running version
+ add-apt-repository should offer next highest repo if matching version is
+ not found
summary: - add-apt-repository should offer next highest repo if matching version is
- not found
+ add-apt-repository should offer next highest repo version if running
+ version is not found
Eric Appleman (erappleman)
summary: - add-apt-repository should offer next highest repo version if running
- version is not found
+ add-apt-repository should offer next highest repo version if repo for
+ running version is not found
description: updated
Revision history for this message
Russell Green (r.green) wrote : Re: add-apt-repository should offer next highest repo version if repo for running version is not found

add-apt-repository just finds out the distro your using using the output from uname and uses that, it doesnt check out information from launchpad.Considering this is an issue that is only going to effect testing users its not really an issue that I think the developers should bother with, what would be cool though is if the add-apt-repository would allow specifying the distro series.

eg. add-apt-repository --series karmic [ppa name]

Eric Appleman (erappleman)
summary: - add-apt-repository should offer next highest repo version if repo for
- running version is not found
+ add-apt-repository should allow version specification or offer next
+ highest repo version if repo for running version is not found
Revision history for this message
Mike Rushton (leftyfb) wrote :

How is it possible that a bug reported 2 months ago is marked a duplicate of the same bug reported 3 hours ago?

Does anyone know how to unmark the original bug as a duplicate and mark this as it should be?

By the way, this application does not look at uname for it's information. Uname is used for the running kernel, not the distribution. This also has nothing to do with polling launchpad or "testing users"

I have specified a good use case in the original bug.

Revision history for this message
Eric Appleman (erappleman) wrote :

Sorry about the duplicate labeling, some guy in #ubuntu-desktop had told me to.

Revision history for this message
amichair (amichai2) wrote :

That would be me :-)

I'm pretty new in this community, and have been working on bugfixing in the software-properties package. As I have been told when I raised the question myself, it's not the date that matters when marking an issue as duplicate, but the amount of information, clarity, or anything else that would make one report seem more useful to the developers than another. If they are more or less equivalent, then it doesn't matter much which is marked as duplicate... any open issue will eventually get fixed (hopefully!), regardless of submitter or date.

The submitter felt that the new submission was clearer - if you feel that the two issues are not the same, or that the earlier one better describes it, or any mistake has been made in either of the reports, feel free to correct them - we're all on the same team here :-)

To unmark a duplicate, I think you just edit the duplicate setting to be blank.

Michael Vogt (mvo)
Changed in software-properties (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Eric Appleman (erappleman) wrote :

With Maverick repos open, this bug once again rears its ugly head.

Revision history for this message
Eric Appleman (erappleman) wrote :

Any hope for the Oneiric cycle.

I know a fair amount of Python, but don't want to do this myself.

D:

Revision history for this message
林博仁(Buo-ren, Lin) (buo-ren-lin) wrote :

Any hope for the Yakkety cycle.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.