Bug#927374: ITP: libstring-elide-parts-perl -- module to elide a string with multiple parts of different priorities

Description : module to elide a string with multiple parts of different priorities this module provides some elision methods for string and handles priorities in order to show the most valuable information when space is reduced. It is a requirement for libprogress-any-output

Re: Different priorities on different architectures

On Wed, 2018-03-21 at 23:18 +0300, kact...@gnu.org wrote: > Hello! > > Recently I got report (and I can confirm) that libgdbm5_1.14.1-6 have > different priorities on x86 and amd64. In source package it is > optional, I checked. The package priority is architecture-independe

Re: Different priorities on different architectures

On 2018-03-21 23:18 +0300, kact...@gnu.org wrote: > Recently I got report (and I can confirm) that libgdbm5_1.14.1-6 have > different priorities on x86 and amd64. In source package it is > optional, I checked. Probably you installed a locally built version of libgdbm5 on your amd

Different priorities on different architectures

Hello! Recently I got report (and I can confirm) that libgdbm5_1.14.1-6 have different priorities on x86 and amd64. In source package it is optional, I checked. I doubt it matter, but that they have different versioned dependencies on libc. Any suggestions, what else to check and how to fix

Re: Priorities overrides? Extra?

iff against the current state on import, it wouldn't necessarily need to be in a list. But I don't really care. I mostly care about sections without components and priorities. ;-) Kind regards Philipp Kern

Re: Priorities overrides? Extra?

installation time that he wants to have f.e. "Debian Astro" > installed, that none of the included packages have conflicts? I thought the task of making a distribution out of a bunch of packages involves more than just running a script that show which packages can be coinstalled. >

Re: Priorities overrides? Extra?

On Mon, Apr 11, 2016 at 5:49 AM, Philipp Kern wrote: > Maybe it's time to acknowledge that it's mostly busy work at this > point and packages could be authoritative for this kind of information (and > handle NEW with a simple list of packages). I expect the ftpteam will want to put things in NEW

Re: Priorities overrides? Extra?

On 2016-04-10 07:08, Ole Streicher wrote: Jakub Wilk writes: * Ole Streicher , 2016-04-10, 14:22: When I look into the "overrides" file for debian stretch: http://ftp.debian.org/debian/indices/override.stretch.main.gz I find there more than 48.000

Re: Priorities overrides? Extra?

ommon task. >> -- either since they are really too special, or since they may have >> conflicts. So, to get the Debian Blends into the installer, what should >> I do? > See? That's why your package should be priority: optional. as thousands other packages. I'd

Re: Priorities overrides? Extra?

On Mon, Apr 11, 2016 at 12:24:55AM +0500, Andrey Rahmatullin wrote: > You can also behave like many packagers do: don't pretend that optional > and extra priorities are different and that the policy (still) has > different requirements about them. I don't see any downsides with that.

Re: Priorities overrides? Extra?

since they are really too special, or since they may have > conflicts. So, to get the Debian Blends into the installer, what should > I do? See? That's why your package should be priority: optional. > I could create bugs for all affected packages (of the blends, and their > dependencies),

Re: Priorities overrides? Extra?

nd their dependencies), which would end up in maybe 1000 bug reports (or commits, if they are team maintained). However, at some point I would have to ask the ftp-masters to change all these priorities, and I am not sure whether they are too happy with it. Best regards Ole

Re: Priorities overrides? Extra?

nd their dependencies), which would end up in maybe 1000 bug reports (or commits, if they are team maintained). However, at some point I would have to ask the ftp-masters to change all these priorities, and I am not sure whether they are too happy with it. Best regards Ole

Re: Priorities overrides? Extra?

hat's all. > Looking into the priorities, I found: > > 66 required > 64 important > 86 standard > 34854 optional > 13191 extra > > which means that almost one third of the packages is priority > "extra". From the policy, I would expect that the main

Re: Priorities overrides? Extra?

Santiago Vila writes: > On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote: >> What is the idea behind the current structure? > > It all depends on what you call "specialized requirements". > > Unless we rely on popcon to decide what's special and what's not, > this

Re: Priorities overrides? Extra?

On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote: > What is the idea behind the current structure? It all depends on what you call "specialized requirements". Unless we rely on popcon to decide what's special and what's not, this will remain very subjective. IMHO, we could well

Re: Priorities overrides? Extra?

Jakub Wilk writes: > * Ole Streicher , 2016-04-10, 14:22: >>When I look into the "overrides" file for debian stretch: >> >>http://ftp.debian.org/debian/indices/override.stretch.main.gz >> >> I find there more than 48.000 overrides; which means that almost >>

Re: Priorities overrides? Extra?

* Ole Streicher , 2016-04-10, 14:22: When I look into the "overrides" file for debian stretch: http://ftp.debian.org/debian/indices/override.stretch.main.gz I find there more than 48.000 overrides; which means that almost *all* packages are overridden. Exactly _all_

Priorities overrides? Extra?

bian/indices/override.stretch.main.gz I find there more than 48.000 overrides; which means that almost *all* packages are overridden. What is the reason for that? I would expect that overriding is something exceptional, but not the common way to set the priority? Looking into the priorities, I fo

Re: Packages of standard priority in a fresh cdebootstrapped system as dependencies of packages with higher priorities.

Thank you, now I understand. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55b33430.7030...@gmail.com

Re: Packages of standard priority in a fresh cdebootstrapped system as dependencies of packages with higher priorities.

Am 24.07.2015 um 20:13 schrieb Jayson Willson: Hello! I have just installed a Debian Stable system with cdebootstrap (cdebootstrap jessie ./ http://ftp.ru.debian.org/debian/) and in this new system I found the following packages, which have standard priority: libcap2 libdb5.3 libgcrypt20

Packages of standard priority in a fresh cdebootstrapped system as dependencies of packages with higher priorities.

Hello! I have just installed a Debian Stable system with cdebootstrap (cdebootstrap jessie ./ http://ftp.ru.debian.org/debian/) and in this new system I found the following packages, which have standard priority: libcap2 libdb5.3 libgcrypt20 libgnutls-deb0-28 libgnutls-openssl27 libgpg-error0

Proper update-alternative priorities for x-www-browser

in the bug the priorities for different browser is not uniform iceweasel is having priority of 70 and chromium browser is having priority of 40 where as some not well known browser is having priority of 100. So shall I reduce the priority of surf from 50 to 40 or 30 or leave it as it is? Do we have some

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

clone 348775 -1 reassign -1 xdg-utils 1.0.2+cvs20100307-3 retitle xdg-utils please introduce (sane) xdg-terminal tags -1 + upstream quit Paul Wise wrote: In xdg-utils CVS there is an xdg-terminal script, not sure why that isn't available in Debian yet: When no desktop is in use, it uses $TERM

Processed (with 1 errors): Re: Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

Processing commands for cont...@bugs.debian.org: clone 348775 -1 Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users Bug 348775 cloned as bug 604959. reassign -1 xdg-utils 1.0.2+cvs20100307-3 Bug #604959 [general] general: terminal emulators' alternatives

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

Hi, Simon Richter wrote: The problem at hand is the proposed (and implemented) solution for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332223 . [lxterm having higher priority than konsole on KDE systems] I'm unconvinced that bumping the priority on the other terminal emulators is an

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

On Thu, Nov 25, 2010 at 1:24 AM, Jonathan Nieder jrnie...@gmail.com wrote: . unlike browsers with $BROWSER and desktop-specific settings, there  is no standard, cross-distro way to make a user-specific choice of  terminal ... To solve (2): one could introduce a TERMINAL environment variable

Re: Which spell checkers to include by default? (Was: priorities)

On Sat, Dec 22, 2007 at 08:08:42AM +0100, Petter Reinholdtsen wrote: If we were to keep a spell checker as part of the default installation, I would suggest using hunspell as it is most advanced and I am told it support the most languages at the moment. The next step would be to change all

Re: Which spell checkers to include by default? (Was: priorities)

On Sat, Dec 22, 2007 at 08:08:42AM +0100, Petter Reinholdtsen wrote: [Anthony Towns] Kind of reviving an old thread, but anyway: It also includes, but afaics, probably doesn't need to (anymore): ispell, dictionaries-common, iamerican, ibritish, wamerican [Agustin Martin]

Re: Which spell checkers to include by default? (Was: priorities)

On Sat, Dec 22, 2007 at 08:08:42AM +0100, Petter Reinholdtsen wrote: Because of this, I believe it would be a good idea to drop ispell from the list of standard packages, and the related packages too (i*, w*). Note that the w* packages provide word lists, which are important to many programs.

Which spell checkers to include by default? (Was: priorities)

[Anthony Towns] Kind of reviving an old thread, but anyway: It also includes, but afaics, probably doesn't need to (anymore): ispell, dictionaries-common, iamerican, ibritish, wamerican [Agustin Martin] #416572: ibritish: Should not have priority standard We now have aspell,

Re: priorities (was: Re: RFC: cups as default printing system for lenny?)

On Fri, Dec 07, 2007 at 12:01:43AM +1000, Anthony Towns wrote: Kind of reviving an old thread, but anyway: It also includes, but afaics, probably doesn't need to (anymore): ispell, dictionaries-common, iamerican, ibritish, wamerican #416572: ibritish: Should not have priority standard

Re: priorities

like package priorities around for much longer. Diverging use-cases (like in this case) show that one definition of standard isn't really helpful anymore. Haven't we more or less already moved away from priorities as meaning anything particularly important? Yes, but we still enforce the formal

Re: priorities

On Mon, Dec 10, 2007 at 05:38:50PM +0100, Marc 'HE' Brockschmidt wrote: Anthony Towns [EMAIL PROTECTED] writes: Priority: standard currently contains: at, bc, dc, lsof, file, less, sharutils, strace dnsutils, ftp, host, ssh, mtr-tiny, finger, w3m, whois doc-debian,

Re: priorities

Hi On Fri, 7 Dec 2007 08:25:05 +0100 NN_il_Confusionario [EMAIL PROTECTED] wrote: Question: is there somewhere on the net a script (*) such that: * it accepts two parameters: a debian release (etch, sarge, woody, ...) and an (empty) directory; * it installs required/essential packages

Re: priorities

On Thu, Dec 06, 2007 at 11:03:08PM -0600, Manoj Srivastava wrote: Frankly, I suggest we look at the list of Unix commands as specified by the SUS -- which can also be seen at: http://en.wikipedia.org/wiki/List_of_Unix_programs So -- how many of the standard unix commands as

Re: priorities

On Fri, Dec 07, 2007 at 07:28:22PM +1000, Anthony Towns wrote: both required and base in the same list, so you have to look for the split yourselve (zlibg1 and adduser atm), but that's not too hard hopefully. Yes it is not _hard_, but it is exactly this sort of dependency hunting that is

Re: priorities

On Fri, Dec 07, 2007 at 08:25:05AM +0100, NN_il_Confusionario wrote: Question: is there somewhere on the net a script (*) such that: * it installs required/essential packages (_all_ of them but _only_ them) of such a release as a chroot in that directory You could create a variant for

Re: priorities

On Fri, Dec 07, 2007 at 04:37:57PM +0900, Michal ??iha?? wrote: On Fri, 7 Dec 2007 08:25:05 +0100 NN_il_Confusionario [EMAIL PROTECTED] wrote: * it installs required/essential packages (_all_ of them but _only_ them) of such a release as a chroot in that directory Isn't minimal flavour in

priorities (was: Re: RFC: cups as default printing system for lenny?)

a system like package priorities around for much longer. Diverging use-cases (like in this case) show that one definition of standard isn't really helpful anymore. Haven't we more or less already moved away from priorities as meaning anything particularly important? We have: required

Re: priorities

Anthony Towns [EMAIL PROTECTED] writes: It also includes, but afaics, probably doesn't need to (anymore): ispell, dictionaries-common, iamerican, ibritish, wamerican m4, texinfo (???) texinfo possibly for info and dating from the days of needing to have an info reader to get real

Re: priorities

On Fri, 7 Dec 2007 00:01:43 +1000, Anthony Towns [EMAIL PROTECTED] said: Haven't we more or less already moved away from priorities as meaning anything particularly important? We have: * required/essential -- stuff that can't be removed: libc, dpkg,etc Packages which are required

Re: priorities

On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote: Anthony Towns [EMAIL PROTECTED] writes: It also includes, but afaics, probably doesn't need to (anymore): ispell, dictionaries-common, iamerican, ibritish, wamerican m4, texinfo (???) texinfo possibly for info and dating

Re: priorities

On Thu, Dec 06, 2007 at 10:26:11AM -0600, Manoj Srivastava wrote: I'm not sure if there's any point to continuing to try to make sure that nothing = optional conflicts with anything else = optional. Hmm. Can you elaborate on this, please? Is it because it is too hard to achieve

Re: priorities

Anthony Towns [EMAIL PROTECTED] writes: On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote: tcsh (people who remember what it is know how to install it) Having a /bin/csh falls into present on all Unix systems and likely to provoke WTF reactions if not there. Which isn't a

Re: priorities

On Fri, Dec 07, 2007 at 04:51:29AM +1000, Anthony Towns wrote: On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote: Anthony Towns [EMAIL PROTECTED] writes: time (???) Likewise. time is a standard Unix program. And which is a built-in on bash, tcsh and zsh, so doesn't seem

Re: priorities

brian m. carlson [EMAIL PROTECTED] writes: On Fri, Dec 07, 2007 at 04:51:29AM +1000, Anthony Towns wrote: On Thu, Dec 06, 2007 at 07:42:06AM -0800, Russ Allbery wrote: Anthony Towns [EMAIL PROTECTED] writes: time (???) Likewise. time is a standard Unix program. And which is a built-in on

Re: priorities

Bernd Zeimetz [EMAIL PROTECTED] writes: Having a /bin/csh falls into present on all Unix systems and likely to provoke WTF reactions if not there. Also, I'm pretty sure that tcsh is very comfortably the second-most-used interactive shell, way ahead of zsh, on Linux systems. Although csh is

Re: priorities

Having a /bin/csh falls into present on all Unix systems and likely to provoke WTF reactions if not there. Also, I'm pretty sure that tcsh is very comfortably the second-most-used interactive shell, way ahead of zsh, on Linux systems. Although csh is the standard on a lot of systems,

Re: priorities

On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff [EMAIL PROTECTED] said: I use time in benchmarking scripts. I do not find the built in time to be a substitute for the good old fashioned time command. Observe: __ time sleep 20 Real: 20.03s User: 0.00s System: 0.00s Percent: 0% Cmd:

Re: priorities

Manoj Srivastava [EMAIL PROTECTED] writes: On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff [EMAIL PROTECTED] said: I use time in benchmarking scripts. I do not find the built in time to be a substitute for the good old fashioned time command. [...] Which is one reason why I wrote

Re: priorities

On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote: On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff [EMAIL PROTECTED] said: I use time in benchmarking scripts. I do not find the built in time to be a substitute for the good old fashioned time command. Observe: Why are

Re: priorities

Anthony Towns [EMAIL PROTECTED] writes: On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote: On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff [EMAIL PROTECTED] said: I use time in benchmarking scripts. I do not find the built in time to be a substitute for the good old

Re: priorities

On Fri, 7 Dec 2007 12:28:55 +1000, Anthony Towns [EMAIL PROTECTED] said: On Thu, Dec 06, 2007 at 05:09:36PM -0600, Manoj Srivastava wrote: On Thu, 06 Dec 2007 13:34:10 -0800, Ben Pfaff [EMAIL PROTECTED] said: I use time in benchmarking scripts. I do not find the built in time to be a

Re: priorities

On Thu, Dec 06, 2007 at 10:26:11AM -0600, Manoj Srivastava wrote: On Fri, 7 Dec 2007 00:01:43 +1000, Anthony Towns [EMAIL PROTECTED] said: * required/essential -- stuff that can't be removed: libc, dpkg,etc Packages which are required to be present for the packaging system to be

Re: priorities

On jeu, 2007-12-06 at 23:11 +0100, Bernd Zeimetz wrote: Although csh is the standard on a lot of systems, including OSX OSX uses bash by default since Panther (10.3). -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL

Re: alternatives and priorities

Wouter Verhelst writes (alternatives and priorities): Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. I have a suggestion: how about we make it a rule that to provide a new alternative with a greater

Re: alternatives and priorities

On Sunday 21 May 2006 16:31, Wouter Verhelst wrote: You would end up with nvi or nano as editors, since they are installed by default. Probably more as viewer and so on. Which is bad why? What I meant was that you would have a high number of installations for the packages that are

Re: alternatives and priorities

priorities. nano is a more sensible default because it is usable by newbies and by people who do not understand the concept of a modal editor. Being popular is overrated... Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: alternatives and priorities

On Mon, May 22, 2006 at 10:42:26PM -0300, Maximiliano Curia wrote: On Sunday 21 May 2006 16:31, Wouter Verhelst wrote: You would end up with nvi or nano as editors, since they are installed by default. Probably more as viewer and so on. Which is bad why? What I meant was that you

Re: alternatives and priorities

Wouter Verhelst [EMAIL PROTECTED] writes: If you have a look at the order of the by_vote numbers for editors, you'll see that vim, not nvi or nano, is at the top. A list like this only seems meaningful if the entries are fairly consistent with each other. For instance, if you have packages

Re: alternatives and priorities

On Tue, May 23, 2006 at 04:55:52PM +0900, Miles Bader wrote: Wouter Verhelst [EMAIL PROTECTED] writes: If you have a look at the order of the by_vote numbers for editors, you'll see that vim, not nvi or nano, is at the top. A list like this only seems meaningful if the entries are fairly

Re: alternatives and priorities

[George Danchev] or some hosts have popularity-contest installed from pure upstream sources instead from a popularity-contest debian package, thus don't have it registered with the dpkg db. That would seriously surprise me, as popularity-contest only is distributed as a Debian package, and

Re: alternatives and priorities

On Fri, May 19, 2006 at 09:51:58PM +0200, Petter Reinholdtsen wrote: [Gregor Herrmann] If you look at by_vote [0] the situation is different: http://popcon.debian.org/main/editors/by_vote [0] which seems more relevant to me: #inst is the number of people who installed this package;

Re: alternatives and priorities

On Fri, May 19, 2006 at 03:23:09PM -0300, Maximiliano Curia wrote: On Friday 19 May 2006 10:25, Wouter Verhelst wrote: So, instead of using static feature lists to define an application's priority with which it would be configured in the alternatives system, why not use popcon data to do

Re: alternatives and priorities

[Wouter Verhelst] Which, I'm sure, is important for popcon maintainers; however, I don't think it is very relevant in this discussion (unless you can point me towards an editor that is implemented as a library ;-) The problem do not only affect libraries. There are other packages (with user

Re: alternatives and priorities

On Sunday 21 May 2006 22:48, Petter Reinholdtsen wrote: --cut-- Heck, even the installation number have problems. Just check out URL:http://qa.debian.org/developer.php?popcon=popularity-contest, showing that 99.72% of the machines reporting to popcon have popcon installed. I believe that

Re: alternatives and priorities

Goswin von Brederlow [EMAIL PROTECTED] writes: Similary any vi extension should top vi itself. Also zile, emacs, xemacs build kind of a progression. Kind of progression?? -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia -- To

Re: alternatives and priorities

Hello! On Fri, 19 May 2006 08:46:28 -0500, Wouter Verhelst wrote: On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote: At 1148052328 past the epoch, Wouter Verhelst wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair

alternatives and priorities

Hi, Today, after upgrading my system, suddenly mcedit became the default editor, rather than vim as I expected it. Investigating showed that some funny guy decided that mcedit could use a priority of 100, whereas vim had fallen back to 60 since the latest upgrade. Fixing this wasn't very hard,

Re: alternatives and priorities

At 1148052328 past the epoch, Wouter Verhelst wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Thoughts? Interesting idea, but by my reckoning that would make ed the default editor for most people,

Re: alternatives and priorities

At 1148048910 past the epoch, Jon Dowland wrote: Interesting idea, but by my reckoning that would make ed the default editor for most people, which I don't think is a good idea: http://popcon.debian.org/main/editors/by_inst Eek. Of course if you go by vote, then vim or nvi trump ed,

Re: alternatives and priorities

On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote: Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. Mm -- I always wondered why xfce-session-manager had a priority over gnome-session-manager

Re: alternatives and priorities

On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote: At 1148052328 past the epoch, Wouter Verhelst wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Thoughts? Interesting idea, but by

Re: alternatives and priorities

On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Interesting idea, but by my reckoning that would make ed the default editor for most people,

Re: alternatives and priorities

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Dowland wrote: At 1148052328 past the epoch, Wouter Verhelst wrote: Using popcon would ensure that the applications which most people prefer would be the default; this is a fair and objective criterion. Thoughts? Interesting idea, but by

Re: alternatives and priorities

Steinar H. Gunderson [EMAIL PROTECTED] writes: On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote: Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. Mm -- I always wondered why

Re: alternatives and priorities

At 1148053588 past the epoch, Wouter Verhelst wrote: That's not an issue. First, ed doesn't install an alternatives for editor. Ah. Of course :) Sheepish, -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact

Re: alternatives and priorities

On Fri, May 19, 2006 at 03:41:12PM +0200, Steinar H. Gunderson wrote: On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote: Fixing this wasn't very hard, but it made me consider why we let a maintainer decide what the alternative priority of an editor would be. Mm -- I always

Re: alternatives and priorities

to 60 since the latest upgrade. Not really on topic, but regarding the relative alternative priorities of vim, nvi, and mcedit have a look at #367991 (summary: as vim maintainers we asked the mc maintainer to lower the alternative priorities of that package). Cheers. -- Stefano Zacchiroli

Re: alternatives and priorities

On Friday 19 May 2006 10:25, Wouter Verhelst wrote: Today, after upgrading my system, suddenly mcedit became the default editor, rather than vim as I expected it. Investigating showed that some funny guy decided that mcedit could use a priority of 100, whereas vim had fallen back to 60 since

Re: alternatives and priorities

[Gregor Herrmann] If you look at by_vote [0] the situation is different: http://popcon.debian.org/main/editors/by_vote [0] which seems more relevant to me: #inst is the number of people who installed this package; #vote is the number of people who use this package regularly; Note, the

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

system-wide, not only under GNOME). I'm not sure about demoting the priorities. I think priorities should decrease with the number of users because the more specific a package is (in terms of number of users) the more likely you want it to be the default, but I suppose there's no general rule

Re: Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

personal preferences about things that are currently handled through the alternatives system, and the sysadmin's choice (or non-choice, as in the bumping priorities scenario) will affect them. For example, everytime a GNOME or KDE application launches, a lot of dotfiles will be created for me, so

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

Hi, On Wed, Jan 18, 2006, Simon Richter wrote: I'm unconvinced that bumping the priority on the other terminal emulators is an adequate solution, hence I'm opening this general bug for discussion on how to reflect individual users' choices properly. We had a similar problem for GNOME

Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users

Package: general Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The problem at hand is the proposed (and implemented) solution for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332223 . I'm unconvinced that bumping the priority on the other terminal emulators is an

Re: Package priorities: optional vs extra

-utils,base/mount Now, one could parse this, and use grep-available in clever ways to see if the packages conflict, and their priorities. manoj -- I went into the business for the money, and the art grew out of it. If people are disillusioned by that remark, I can't help it. It's

Re: Package priorities: optional vs extra

conflict, and their priorities. I have a really hacky tool available that I used to produce such a list of packages to look at. I even posted it to some list somewhen, one could probably dig it up using google. I don't seem to have committed it to my personal CVS repository (silly me) so I don't havee

Re: Package priorities: optional vs extra

On Mon, Jul 11, 2005 at 01:21:35PM +0200, Frank Lichtenheld wrote: I have a really hacky tool available that I used to produce such a list of packages to look at. I even posted it to some list somewhen, one could probably dig it up using google. I don't seem to have committed it to my personal

Re: Package priorities: optional vs extra

Peter Samuelson wrote: In practice, 'extra' is mainly used when Policy forces you to use it: that is, if your package conflicts with another package which has priority optional or higher The really sad part is that *this* isn't enforced; there are lots of optional packages which conflict with

Re: Package priorities: optional vs extra

su, 2005-07-10 kello 01:44 -0400, Nathanael Nerode kirjoitti: Peter Samuelson wrote: Unless someone is willing to actually enforce the requirement that all optional packages can coexist, this will be necessary to make Policy conform with reality. Is there a tool to check for disallowed

Re: Package priorities: optional vs extra

On Mon, Jul 04, 2005 at 04:06:22PM -0500, Peter Samuelson wrote: [Lionel Elie Mamane] I recently found some packages in at an IMHO totally wrong priority in Debian. Yeah. I've been grumbling about optional vs. extra for years. Nobody wants to consider his own packages 'extra' because

Re: Package priorities: optional vs extra

[Lionel Elie Mamane] I recently found some packages in at an IMHO totally wrong priority in Debian. Yeah. I've been grumbling about optional vs. extra for years. Nobody wants to consider his own packages 'extra' because every maintainer feels his own packages are Really Useful. This is a

Package priorities: optional vs extra

I recently found some packages in at an IMHO totally wrong priority in Debian. Before taking action, I'd like to arrive at a rough consensus here. I also found some less clear-cut cases, so this prompted me to think a bit about the language in the policy and what it means. The more I think about

Re: requirements regarding 'priorities'

Hi, Wolfgang Sourdeau wrote: What can be done, regarding this package, and also every other packages which could be in this situation? At the moment? Not much. It's a low-priority problem. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]

requirements regarding 'priorities'

values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. Pascal Giard (CC'd in this message) is trying to be compliant with this, but any upload of the package makes the ftp system send a message stating

Re: update-alternatives priorities for editors

Adam Heath wrote: /usr/bin/vi should be an alternative for vi-compatible editors. /usr/bin/vi should then be an alternative that is hooked into /usr/bin/editor. But, but, but... How does it work if /usr/bin/vi is an alternative hooked into /usr/bin/editor? What package would own that hook?

Re: update-alternatives priorities for editors

Georg Neis wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=121303 Elvis as the standard editor (priority 120) is not very convenient. Imagine a newbie thrown into elvis, and he will be lost, and cannot quit:( This bugreport says that the elvis package (a vi clone) uses a too high

Re: update-alternatives priorities for editors

On Thu, Jul 24, 2003 at 11:00:56PM -0600, Bob Proulx wrote: Georg Neis wrote: This bugreport says that the elvis package (a vi clone) uses a too high priority for the 'editor'-alternative (or for all alternatives?). Which changes do you propose? As I read the original bug report and

Re: update-alternatives priorities for editors

Am 25.07.03 um 09:21:47 schrieb Colin Watson: /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. Shouldn't that be sensible-editor? Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831

  1   2   >