Latest ideas - Ubuntu brainstorm

Ubuntu QA:

Blog

Brainstorm

Package status

Synaptic package manager

Idea sandbox

Popular ideas

Ideas in development

Implemented ideas

Here are the latest ideas about Synaptic package manager that have been approved.

Many applications don't have .deb packages on their download pages

Written by Clorox the 28 Jul 09 at 21:09. New

This is very common - I show Ubuntu to my friend, he/she likes it, then tries to go to a website to install a program.

a) He/she downloads an rpm. I show them how to use Alien; they run away from Linux because you have to use the command line.

b) He/she downloads a tgz. This could be anything, such as a source tarball, Slackware package, or an archive containing files that need to be extracted somewhere. I have no idea what to do with it either; they run away from Linux because of bad package formats.

c) He/she downloads a bin file (Google Earth). I have experience with this, so I show them how to use make-googleearth-package; they run away from Linux because you have to use the command line.

d) He/she downloads a deb. Something goes right, and it installs without a hitch.

So software packaging is a huge issue, and there's sort of a war between rpm and deb, and other weird formats.

16
votes

Solution #1: Promote openSUSE Build Service

Written by Clorox the 28 Jul 09 at 21:09.

This way, developers can make packages for the most popular Linux distributions more easily. Once a developer is ready to build packages for his/her software, he/she uses osc to automatically make packages for:

-SUSE/openSUSE
-Red Hat/Fedora/CentOS
-Debian
-Ubuntu
-Mandriva

If you're a developer, install the package "osc", and use it well!

13
votes

12
votes

Solution #3: Include Alien function in gdebi-gtk package installer

Written by kikl the 12 Aug 09 at 16:48.

Adding an alien GUI is a good idea, but I think such a GUI already exists. It's called package converter.

http://code.google.com/p/foxoman/wiki/PackageConverter

If someone downloads an rpm-package and double-clicks it under ubuntu, it is most likely that the wants to install the package. He shouldn't be forced to use a separate tool. Therefore, the package conversion functionality should be included into the package installer. If you double click the rpm-file, the package installer automatically converts and installs the package.

Add a comment or propose a solution >>

I have several old ".appName" folders in my /home

Written by edbian the 23 Jul 09 at 16:07. New

Right now the only way to remove them is to go through the directory 1 at a time and manually decide. I could write a script but it is tough enough to tell on my own which folders need to stay and which should go. They might be hidden but they are mostly wasted space.

9
votes

Solution #1: Add a flag to aptitude (and apt-get, and synaptic)

Written by edbian the 23 Jul 09 at 16:07.

There should be a new flag added to aptitude (and apt-get and a new function added to synaptic). Right now I can "remove" a package which removes most of the files but leaves the /etc config files and the .appName. Alternatively I could "purge" the program which will remove everything except the .appName folder.

I should be able to "sudo aptitude -h remove " which will remove the package and the .appName folder hidden in /home. Alternatively I should be able to "sudo apt-get -h purge " which would remove all of the package files including /etc config files AND the .appName folder in /home. In my opinion this would be a more intuitive "purge" but I don't think it is a good idea to change the meaning of the "purge" command. Too many people will be accidentally removing the .appName folders that they may want to keep.

9
votes

Solution #2: Help users manage leftover .appName folders

Written by Darwin Survivor the 8 Aug 09 at 12:30.

Removing all .appName folders from every user's home folder could cause problems if other users had intended to keep those folders. A better idea may be to make it easier for users to manage and clean their home folders.

I propose we make a way of tracking which applications use which configuration folders (maybe a specially-named file in the root of the config folder) and create a utility that will list folders vs applications and highlight which ones are for applications that no longer exist. The user could then hit a "delete" button and delete the un-used folders they no longer wish to keep.

See the 5 comments or propose a solution >>

Version "pinning" of packages in apt, synaptic, etc

Written by gazilla the 30 Jun 09 at 02:32. New

The concept of version "pinning", or locking a package to a specific version, is missing one essential element...

The ability to lock a specific package OUT of the system completely.

For various social, political, business or technical reasons is may be necessary to stop a package from ever being installed. Synaptic already has the option to lock a package to a specific version. I do not know if this extends to the update manager, or to apt-get. All of these tools appear to lack the option of locking the version to NONE.

This is particularly important is the case of libraries. Without citing real examples, I may need/wish to exclude all applications that rely on 'libblah'. With the vast web of dependencies it is difficult to achieve this by manual checking at each update. I want the package management system(s) to assist me in this task.

8
votes

Solution #1: Add the ability to lock a package OUT

Written by gazilla the 30 Jun 09 at 02:32.

Add the ability of locking a package version to NONE, and have synaptic, update manager and apt-get all honour this arrangement.

EDIT:: After discussions with a Debian packaging guru, it appears that this is partially possible. Adding pinning options to /etc/apt/preferences will block packages, BUT the package names cannot be globbed. So it is possible to block package 'foobar-common', but not 'foobar-*'.

So the problem still stands, but the solution has narrowed to making APT more generally useful. Adding the functionality to synaptic to set globbed pinning options in a GUI is the way to go.

Add a comment or propose a solution >>

Installing certain packages severely decreases system performance

Written by unimatrix the 15 Jun 09 at 07:42. New

This is not a bug. It is just the way it is. For example installing the mysql server directly (or via dependencies - where the user may not even realize it) will decrease system performance and increase boot time. SQL servers have no place on thin clients. Of course mysql isn't the only such example. Some packages also depend on apache, which again shouldn't be installed on thin clients.

10
votes

2
votes

Solution #2: Configure services to launch on-demand.

Written by Michael Safyan the 3 Jul 09 at 23:04.

On the desktop version of Ubuntu (not the server version), system services should be configured to launch on demand, not at system boot, and should also be configured to have as few processes running as possible (e.g. normal apache may have five processes alive waiting for connections at the same time, but on the desktop version, we don't want this forking behavior). This way, users can enjoy the benefits of these services with the bare minimum penalty to system performance. This could be coupled with solution #1, so that users are warned that they are installing daemon processes, but if users choose to go ahead, users get the best performance.

See the 1 comments or propose a solution >>

Tool to generate & maintain Repositories for custom distro's supporting APT

Written by snktagarwal the 12 Jun 09 at 08:21. New

There are many distro's based on Debain which support APT for maintaining/configuring packages/softwares.

The idea is to create a Tool which can help to generate and maintain Mirrors for Custom distributions, the major motivation and features that I wish to impl are as follows:

* Ability to specify a subset of packages already included in the existing Global Repositories.
* Adding custom packages, distribution specific!
* Identifying dependencies, both for existing and custom packages.
* Downloading and Mirroring the packages thus identified to the target server.

Major Use Cases:

1. Augment the already existing Global Mirrors with distro specific version of Packages.
2. Create a whole new Partial Mirror.

What do you think about the utility of such a tool ?

-2
votes

Add a comment or propose a solution >>

dependency hell etc..

Written by dario84 the 10 Jun 09 at 21:11. New

the problem exists when you want to install application which is using libraries that are already installed in the system but not in exact version or are not available in the system.

7
votes

Solution #1: Package Management System to install apps with all dependencies in the package

Written by dario84 the 10 Jun 09 at 21:11.

Provide package management system which allows users to install pre-built software packages from a single executable file - in the opensource world there is something similar in PC-BSD (http://www.pbidir.com , http://www.pcbsd.org/content/view/20/26/ ).

I think such a system could be very good addition for standard managers like apt(yum,yast etc.., something like this could standarise software management in all linux distributions ) and could solve the dependency hell!! I want to stress that it should be only an addition so not in place of apt.

7
votes

Solution #2: Allow multiple versions of packages to coexist.

Written by Michael Safyan the 3 Jul 09 at 22:59.

Design packages in such a way that multiple versions can coexist. One way to do this is via symbolic links:

/usr/share/include/pkg-v1.0.0
/usr/share/include/pkg-v1.0 -> /usr/share/include/pkg-v1.0.0
/usr/share/include/pkg-v1 -> /usr/share/include/pkg-v1.0
/usr/share/include/pkg -> /usr/share/include/pkg-v1

I believe something like this is already done with shared libraries. Packages which depend on a specific version of a package should reference the version-specific location, not the default/current location, which may change.

2
votes

Solution #3: Use chroot attached to specific repository

Written by Lachu the 16 Jul 09 at 14:27.

You should think about a repo as system/software provider. Each have different set of apps or one app could be different than the same in other repository.

I think you should provide new way to solve dependency problem. Each repo should have owned directory. When you cannot install some software, user can asks to install it in chrooted environment for package source repository. Idea also includes think about using aufs. Installed software in repository directory will be run via chroot, so we must provide way to see normal system.

After creation new environment system should think there's no package installed or package database should be copied to repo dir.

See the 7 comments or propose a solution >>

The apt line is release-specific

Written by yman the 3 Jun 09 at 20:36. New

Currently when specifying a repository, one has to specify release-specific information. This information then has to be updated when the operating system is updated.

-26
votes

Solution #1: Meta-Repositories

Written by yman the 3 Jun 09 at 20:36.

Have "meta-repositories" that list each operating system release and it's corresponding apt line. For example:

Ubuntu : 8.04 : deb http://packages.medibuntu.org/ hardy free non-free
Ubuntu : 8.10 : deb http://packages.medibuntu.org/ intrepid free non-free
Ubuntu : 9.04 : deb http://packages.medibuntu.org/ jaunty free non-free

The repository manager will then automatically select the appropriate "real" repository.

In addition, the "meta-repository" can also contain scripts that are needed for transitioning from one "real" repository to the next.

40
votes

-13
votes

6
votes

Solution #4: Move the version to a different file

Written by gazilla the 5 Jun 09 at 09:59.

The sources.list file is just that: A list of sources, or more precisely a list of locations. So take the version out of sources.list and put it in a file of its own [say] version.conf or perhaps in apt.conf.d somewhere. That would make sources.list like this...

deb http://packages.medibuntu.org/ free non-free

The sources.list line would not change from one version to the next. This would be just a useful for Debian as they could put "stable" or "testing" in version.conf where we might put "jaunty" or "karmic". Having just finished a bunch of upgrades from hardy, thru intrepid, to jaunty this would have saved some fiddling.

See the 9 comments or propose a solution >>

Generate Revenue for DEVELOPERS

Written by macvr the 17 May 09 at 07:19. New

hi,
i love open source and the loads of free stuff .

But here is the problem with open source developers> developers dont get paid , and over the course loose interest over their NON-paying hobby projects , or they are not able to maintain their product due to lack of funds for the network hosting, etc.

Not to blame the developers, but DEVELOPERS NEED TO EAT, they need to have money to concentrate on the free product they are making. else they tend to take more interest towards their paying jobs eventually they loose all interest in their open source program.

there have been many examples[not to name specific softwares], where the developers have blocked the repos for lack of funds to keep the site running, devs dropping out of projects and asking for someone else to take over the project.

imagine the possibility of a free equivalent products ,which work as good as the proprietary programs or even better.

Open source CANNOT sustain itself unless devs get money.
and i hate the donate buttons[some sites are still labeled donate], it should be more appropriately labeled "contribute".

i admit, i have never donated to any open source projects, and so also the millions of other users who have not donated.

but there must be a way to generate free content for users and also get money to the devs making us happy.

once there is revenue for the devs, more might be attracted to create programs,more innovative ideas,more competition, more choices, better products.
this would give us better quality and we would have better support for the programs.

[....]

-31
votes

Solution #1: NEW REPOSITORY for developer revenue

Written by macvr the 17 May 09 at 07:19.

pls read fully ,before u get nauseated by the notion:
*** links to the project are already provided in the synaptic package description ***
*** the need is because ,no matter how well the links to the project are presented the contributions are not good enough. ***

*** THIS IS AN OPTIONAL opt-in SERVICE ***

*** this is ONLY FOR developers who request this. ***

setup a new repository[much like universe/multiverse] for developers, who decide that they need money for continued maintenance of their products.

the rules need to be set:
1:the user selects this repo for access to the products, AND has the option to contribute to the project via OPT-IN ads.

2:the USER DOES NOT HAVE THE OBLIGATION to view ads, but can choose to do so. this way the users who choose to contribute to the project but unwilling to pay via a donate button.if user has opted for ads, he is reminded at the appropriate time to view the ad in the browser.

3:USER CAN AT ANY TIME OPT-OUT and stop ads at any time he wishes.

[...]

4:user decides on the limit of ads he decides to view [X perday/perweek] and also the time when he wants to view them.

5:when the user doesnt accept ads> the user is reminded, at every software update for the program, that he has chosen a program where the dev has requested contributions for continued support of the program, and it would help the developer sustain the product.

6:using something similar to popularity contest, note the number of users using the software and pay the dev according to popularity of software and ads generated.

7:the revenue generated for the project is displayed on site[example:ubuntu.ad.repos.com], where revenue for the month/year/total is shown...along with the amount the dev requires to maintain the project... so when the users feel that enough revenue is being generated they can opt-out of the ads.

8:canonical pays from this revenue, the extra employees needed to maintain this repo and its quality control.

this may seem far fetched to allow ads in linux , but unless the small devs get paid ,quality products wont be unlimited.

take google for example: its free, we all enjoy it free but it gets paid by ads and the devs get paid pretty well.we also have the option of using customize google extension where we can block ads.

this is almost like apple app store but FREE for the users.

the most important thing is that since
1> the dev sets the amount required to support his project ,
2> the repo controllers agree that the requirement is not too huge
3> as the users accumulate for that project ,the users might not even need to view more than a single ad a month for maintaining the project. if its in the millions of users for the project maybe one ad a year. that is definitely not a burden for anyone!

BOTTOM LINE IS DEVELOPERS NEED TO BE COMPENSATED FOR THE LOVELY PROGRAMS THEY CREATE.AND TO KEEP CREATING MORE PROGRAMS.

*** THIS IS AN OPTIONAL opt-in SERVICE ***

*** this is ONLY FOR developers who request this. ***

setup a new repository[much like universe/multiverse] for developers, who decide that they need money for continued maintenance of their products.

the rules need to be set:
1:the user selects this repo for access to the products, AND has the option to contribute to the project via OPT-IN ads.

2:the USER DOES NOT HAVE THE OBLIGATION to view ads, but can choose to do so. this way the users who choose to contribute to the project but unwilling to pay via a donate button.if user has opted for ads, he is reminded at the appropriate time to view the ad in the browser.

3:USER CAN AT ANY TIME OPT-OUT and stop ads at any time he wishes.

4:user decides on the limit of ads he decides to view [X perday/perweek] and also the time when he wants to view them.

5:when the user doesnt accept ads> the user is reminded, at every software update for the program, that he has chosen a program where the dev has requested contributions for continued support of the program, and it would help the developer sustain the product.

6:using something similar to popularity contest, note the number of users using the software and pay the dev according to popularity of software and ads generated.

7:the revenue generated for the project is displayed on site[example:ubuntu.ad.repos.com], where revenue for the month/year/total is shown...along with the amount the dev requires to maintain the project... so when the users feel that enough revenue is being generated they can opt-out of the ads.

8:canonical pays from this revenue, the extra employees needed to maintain this repo and its quality control.

this may seem far fetched to allow ads in linux , but unless the small devs get paid ,quality products wont be unlimited.

take google for example: its free, we all enjoy it free but it gets paid by ads and the devs get paid pretty well.we also have the option of using customize google extension where we can block ads.

this is almost like apple app store but FREE for the users.

the most important thing is that since
1> the dev sets the amount required to support his project , 
2> the repo controllers agree that the requirement is not too huge 
3> as the users accumulate for that project ,the users might not even need to view more than a single ad a month for maintaining the project. if its in the millions of users for the project maybe one ad a year. that is definitely not a burden for anyone!

BOTTOM LINE IS DEVELOPERS NEED TO BE COMPENSATED FOR THE LOVELY PROGRAMS THEY CREATE.AND TO KEEP CREATING MORE PROGRAMS.

53
votes

Solution #2: Link to the project website/provide dev's e-mail

Written by Ssdg the 18 May 09 at 14:29.

You might know that a lot of FOSS devellopers are already paid. (exemples: Bigger Kernel devs by Linux vendors like red hat, eclipse devs by IBM,...)

But in case of benevolent projects, you can't find thoses informations easily, so why not promoting the project website in package/program description?

Most FOSS projects allow people to pay via paypal already,so why adding a repository or any other method that needs the original develloper to "sign-up"? Let's use his/her favorite way of getting paid.

6
votes

Solution #3: Ubuntu App Store

Written by otakuj462 the 1 Jun 09 at 16:17.

Despite its closed nature, Apple's App Store has proven to be a tremendous success. The App Store model involves a central organization that approves and distributes commercial applications directly to users. The central organization takes a small percentage of the revenue generated on each app sold; the rest of the revenue goes directly in the pocket of the developer. The overall goal is to make it as easy as possible to connect users who want to pay for high-quality free software, to developers who want to produce that software.

It is very easy to imagine Canonical acting as the the central distributor in this model, as it currently performs this role already with software that is free-as-in-beer (much of it is free-as-in-speech as well). Additionally, much of the core technologies required for such an app store to exist are already in place: distribution, packaging and installation is all provided by apt; Synaptic provides a convenient graphical front-end for installation and package management. Perhaps, with small extensions to these existing systems, it would be possible to create an infrastructure to allow for individual payments to application developers.

Just off of the top of my head, here is what this might involve: It seems likely that this would involve the addition of a special repository for software for which the developer would like to be paid; let's call it a repository for "contribution-based" software. Apt package info may be extended to support monetary value as extra meta-information. Every apt front-end would then need to be modified to respect this extra monetary meta-information. The apt front-ends should be able to integrate with a centralized data store that tracks various payment methods, such as a credit card, or paypal credentials. Synaptic would perhaps be extended to allow the filtering of contribution-based software, perhaps with a dedicated button that include/excludes such software. Other GUI tweeks would be possible.

[...]

I can already see many problems with the above (what happens if you're using an older apt client that doesn't respect financial meta-information; the package gets downloaded for free). There are almost certainly more elegant ways to solve this problem that will be apparent to other Debian and Ubuntu developers, and I encourage you to elaborate on how this might work from a technical standpoint.

It is also important to note that while Apple's app store primarily hosts non-free software (free as in beer, and free as in speech), and uses DRM to ensure that users do not make copies of this software, I believe that neither of these features are essential to the success of an Ubuntu App Store. It is possible to imagine individual users swapping .deb's of contribution-based software via filesharing networks, or visiting the authors' websites to compile "contribution-based" software from source and package it by hand; and, according to the terms of the GPL, and most other free software licenses, they would be completely within their rights to do so. However, such methods are much less convenient than simply clicking through a graphical interface, and obtaining your packages directly from Canonical, especially with respect to the demographic of non-technical users that Canonical would like to target. Just so long as value is added to the software in some way, be it by way of convenience or by some other means, then a "contribution-based" repository will be used over other methods of obtaining and installing the software. Additionally, I feel that many Ubuntu users would like to see developers get paid, and thus would be more inclined to use such a service.

In conclusion, while putting a price on software that has otherwise been free-as-in-cost might at first seem a bit unusual, we must consider that providing a convenient, direct mechanism for developers to be paid for their software will help, not harm, the Ubuntu GNU/Linux distribution, the ecosystem of free-as-in-speech software, and the Free Software Movement in general. It will attract more users and more developers to the Ubuntu GNU/Linux platform, especially as such a mechanism does not exist on Microsoft Windows. One need only look to the success of the Apple App Store, and Sun's soon-to-be-launched Java app store, to see that there is a demand for such a distribution model.

It is very easy to imagine Canonical acting as the the central distributor in this model, as it currently performs this role already with software that is free-as-in-beer (much of it is free-as-in-speech as well). Additionally, much of the core technologies required for such an app store to exist are already in place: distribution, packaging and installation is all provided by apt; Synaptic provides a convenient graphical front-end for installation and package management. Perhaps, with small extensions to these existing systems, it would be possible to create an infrastructure to allow for individual payments to application developers.

Just off of the top of my head, here is what this might involve: It seems likely that this would involve the addition of a special repository for software for which the developer would like to be paid; let's call it a repository for "contribution-based" software. Apt package info may be extended to support monetary value as extra meta-information. Every apt front-end would then need to be modified to respect this extra monetary meta-information. The apt front-ends should be able to integrate with a centralized data store that tracks various payment methods, such as a credit card, or paypal credentials. Synaptic would perhaps be extended to allow the filtering of contribution-based software, perhaps with a dedicated button that include/excludes such software. Other GUI tweeks would be possible.

It is also important to note that while Apple's app store primarily hosts non-free software (free as in beer, and free as in speech), and uses DRM to ensure that users do not make copies of this software, I believe that neither of these features are essential to the success of an Ubuntu App Store. It is possible to imagine individual users swapping .deb's of contribution-based software via filesharing networks, or visiting the authors' websites to compile "contribution-based" software from source and package it by hand; and, according to the terms of the GPL, and most other free software licenses, they would be completely within their rights to do so. However, such methods are much less convenient than simply clicking through a graphical interface, and obtaining your packages directly from Canonical, especially with respect to the demographic of non-technical users that Canonical would like to target. Just so long as value is added to the software in some way, be it by way of convenience or by some other means, then a "contribution-based" repository will be used over other methods of obtaining and installing the software. Additionally, I feel that many Ubuntu users would like to see developers get paid, and thus would be more inclined to use such a service.

In conclusion, while putting a price on software that has otherwise been free-as-in-cost might at first seem a bit unusual, we must consider that providing a convenient, direct mechanism for developers to be paid for their software will help, not harm, the Ubuntu GNU/Linux distribution, the ecosystem of free-as-in-speech software, and the Free Software Movement in general. It will attract more users and more developers to the Ubuntu GNU/Linux platform, especially as such a mechanism does not exist on Microsoft Windows. One need only look to the success of the Apple App Store, and Sun's soon-to-be-launched Java app store, to see that there is a demand for such a distribution model.

See the 5 comments or propose a solution >>

Windows Programs Names in Synaptic Package Manager

Written by lhb1142 the 6 May 09 at 13:56. New

In almost every case there is a Linux equivalent for a given Windows (or even a Mac) program.

However, it is sometimes difficult to determine which Linux program is an equivalent for the program one desires.

-43
votes

Solution #1: Place Windows/Mac Program Name in Synaptics Package Manager Description

Written by lhb1142 the 6 May 09 at 13:56.

It would be helpful to place in the description of a Linux program the name of the Windows or Mac program to which it is an equivalent.

This would allow one to find an equivalent program by using the Search function in the Synaptics Package Manager.

An example for this (which has already been implemented) is DVDShrink, a Windows program. If you search for DVDShrink in Synaptics Package Manager, you are presented with two Linux program choices; these are presented because they have the name DVDShrink within their descriptions.

If necessary, a notice next to the Windows program name could be inserted stating that the Windows program name is the property of the respective company which owns it; I believe this would satisfy any legal requirements.

-26
votes

Solution #2: Add a column for that lists similar programs.

Written by Darwin Survivor the 7 May 09 at 05:41.

There should be a column, or at least a section of the description, that lists similar applications. These could be other applications in Synaptic or applications from other Operating Systems.

This would also allow people to try a program (eg. evolution), and if they don't like it, they can look at the list of similar applications and try something else (kmail, Thunderbird, etc).

Making it a "alternative to windows application X" makes Linux look like no more than a windows alternative. We need to make Linux stand out on it's own.

-18
votes

37
votes

0
votes

6
votes

Add a comment or propose a solution >>

It's redundant having to choose necessary packages.

Written by salemboot the 6 May 09 at 05:11. New

Installing new software in Synaptic requires one to know the application name they are looking for. They need to have some idea about the details of the problem they may need a solution for. Finally, It requires separate selections to install the documentation and development packages of the application being sought after.

11
votes

Solution #1: Changes to Synaptic to include Software Package Groups

Written by salemboot the 6 May 09 at 05:11.

It'd be helpful to have selectable package groups to install applications which would solve a task a user is requesting. Examples of which would be, Photography where a group of images editing applications are grouped and pre-selected. Much in the same way that 'build-essential(s)' retrieves several development packages.

While currently there are categories such as graphics and office, this is insufficient if the person then notices there are three packages for the one application. It's a given someone wants documentation for the application they are installing.

This would reduce the vagueness of Synaptic. A person would see task oriented solutions to the installation of new software.

An option to install all available packages for a particular software program would aid software developers as well.

It may be helpful to hide all but the prime package and list it by its proper name rather than the full file name. An image icon for the application may be more aesthetically appeasing as well.

43
votes

3
votes

Solution #3: More categories. Allow apps to have tags. Graphical packages

Written by weblordpepe the 28 May 09 at 12:28.

For example, VLC could be tagged 'multimedia, video, audio, streaming' and those could all be search queries.

Represent package names by icons, along with descriptions. Just like you are browsing a gallery of some kind (I guess you are).

Back end libraries could be tagged as 'library' and as such Synaptic should have smarts to put them out of the way by default. Same with drivers, source code, and any package which isn't an actual application.

Synaptic needs much more smarts.

See the 5 comments or propose a solution >>

<< Previous 1 2 3 4 5 6 7 8 9 ... Next >>

Submit your idea