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-independent.

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?

e implemented as a diff 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?

someone > chooses at 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 b

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 overrides; which means that almost *all* packa

Re: Priorities overrides? Extra?

gt;> -- 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 have no problems t

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 wi

Re: Priorities overrides? Extra?

ler. > -- 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. > I could create bugs for all affected packages (of the blends, and

Re: Priorities overrides? Extra?

encies), 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?

encies), 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?

#x27;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

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 will remain very sub

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 get

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 >> *all* packages are overridden. > > Exac

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_ binary packages are in th

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 > libgc

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

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

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 emulato

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 $TER

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

On Thu, Nov 25, 2010 at 1:24 AM, Jonathan Nieder 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 > analogous to M

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

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 Mart

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, my

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-debia

Re: priorities

>> quite uncomfortable with keeping 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 fro

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 standa

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 usele

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 debo

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

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 fl

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 pa

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

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 PROTECT

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 tim

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 th

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:

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

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

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. > Alt

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, i

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

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 terr

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." > Wh

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 achi

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 a

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

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

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

mfortable with keeping 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

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 alter

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, an

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

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 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 t

Re: alternatives and priorities

e should not use popcon to decide alternatives 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

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 inst

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 --

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 > 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 whe

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 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

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: > > # is the number of people who installed this package

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 i

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: > # is the number of people who installed this package; > # is the number of people who use this package regularly; Note, the popcon

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 sinc

Re: alternatives and priorities

; had fallen back 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. -- Stefan

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

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

"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 xfce

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 id

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 p

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 id

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

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: > Eek. Of course if you go by "vote", then vim or nvi tr

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 pe

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, bu

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

because it makes sense 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, b

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

ls. Many users have 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

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 G

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 adequa

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 perso

Re: Package priorities: optional vs extra

grep-available in clever > ways to see if the packages 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 com

Re: Package priorities: optional vs extra

ols,utils/kbd bin/mount admin/loop-aes-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 disillu

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 c

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

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'

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 s

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 it

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'

t not depend on packages with lower priority 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

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

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. Yeah, I've always wanted to resolve 6 levels of symlinks to get to my editor. -- see shy jo pgpULHcwFmFrZ.pgp Description: PGP

Re: update-alternatives priorities for editors

On Thu, 24 Jul 2003, Bob Proulx wrote: > As I read the original bug report and apply my own spin onto it I see > the original poster was concerned that a user invoking /usr/bin/editor > is probably not wanting either of the traditional vi or emacs editors. > They are probably a user that wants a s

Re: update-alternatives priorities for editors

Manoj Srivastava <[EMAIL PROTECTED]> writes: > On Fri, 25 Jul 2003 09:21:47 +0100, Colin Watson <[EMAIL PROTECTED]> said: > >> /usr/bin/editor is not only something invoked directly. It's also >> invoked by programs as the default editor. And, if vim is the only >> editor installed on the system,

  1   2   >