Re: Upstream Tracker

[Andrey Ponomarenko]

On 07/19/2010 04:34 AM, Erik de Castro Lopo wrote:
> Andrey Ponomarenko wrote:
>
>   
>> Hello, Colleagues!
>>
>> The new service for tracking ABI changes in various C/C++ libraries is
>> now available for Linux distribution maintainers and upstream developers
>> - "Upstream Tracker". It may be helpful for analyzing risks of libraries
>> updating in the Debian Linux. The service includes more than 100
>> libraries at the moment: OpenSSL, ALSA, glib, cairo, libssh, fontconfig etc.
>>
>> The service is freely available at:
>> http://linuxtesting.org/upstream-tracker/
>>
>> Suggestions for libraries inclusion and feature/bug requests are very
>> welcome. Thanks!
>> 
> That is fantastic
>
> I was very pleased to see my libsrary libsndfile up there:
>
> http://linuxtesting.org/upstream-tracker/versions/libsndfile.html
>
> Would also love to see my other library libsamplerate up there:
>
> http://www.mega-nerd.com/libsamplerate/download.html
>   

Added to:
http://linuxtesting.org/upstream-tracker/versions/libsamplerate.html

> Cheers,
> Erik
>   


-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org
 mail:   upstream-trac...@linuxtesting.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c43f898.1020...@ispras.ru

Re: packages being essential but having stuff in /usr/?!

[Patrick Schoenfeld]

On Fri, Jul 16, 2010 at 07:30:17PM +0200, Christoph Anton Mitterer wrote:
> What about /etc?

Well, this one is easy: /etc *can not* be on its own partition.
It has to be on the root filesystem so it will be available.

Regards,
Patrick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100719081649.ga23...@debian

Bug#589613: ITP: r-cran-outliers -- A collection of some tests commonly used for identifying outliers.

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: r-cran-outliers
  Version : 0.13-2
* URL : http://cran.r-project.org/web/packages/outliers/index.html
* License : GPL-2
  Programming Lang: R
  Description : A collection of some tests commonly used for identifying 
outliers.

Just give me the number, the package is almost ready.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100719090116.2612.1470.report...@moeller-desktop

Re: Priority dependence

[Bernhard R. Link]

* Russ Allbery  [100718 19:30]:
> Ideally, it would be nice to be able to sort out packages by priority and,
> from that, build, say, a CD set of only the important and higher packages
> and know that it's self-contained.  In practice, I suspect that we have
> enough packages with problems here that you have to compute the dependency
> closure anyway, but insofar as priorities are useful for anything, I think
> that was the goal.

Calculating a dependency closure is neither an easy nor an task with
a well-defined outcome. Starting with more data makes that both more
easy and more likely to come to deterministic results (with a good
enough starting set, most dependencies will most likely already be in
that set, so the likelyhood to encounter virtual packages or or-ed
dependencies (especially those were different packages have different
first choices) is much smaller.

The difference between optional and extra is indeed mood today. But I
guess that is mostly because dh_make is making everything optional
instead of extra by default...

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100719104154.ga6...@pcpool00.mathematik.uni-freiburg.de

Re: Xen for Squeeze, 3.4 or 4.0

[Toni Mueller]

Hi,

I know that I'm a bit late...

On Thu, 10.06.2010 at 17:54:28 +0200, Bastian Blank  wrote:
> My personal preference would be to go with 4.0.

If it's one, then I opt for 4.0.

Thank you very much!


Kind regards,
--Toni++


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100719104308.5890.qm...@oak.oeko.net

Re: Priority dependence

[Simon Richter]

Hi,

On Mon, Jul 19, 2010 at 12:41:54PM +0200, Bernhard R. Link wrote:

> The difference between optional and extra is indeed mood today. But I
> guess that is mostly because dh_make is making everything optional
> instead of extra by default...

Most packages can be "optional", since they don't introduce conflicts.

   Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100719110007.ga3...@richter

Re: Priority dependence

[Peter Pentchev]

On Mon, Jul 19, 2010 at 12:41:54PM +0200, Bernhard R. Link wrote:
> * Russ Allbery  [100718 19:30]:
> > Ideally, it would be nice to be able to sort out packages by priority and,
> > from that, build, say, a CD set of only the important and higher packages
> > and know that it's self-contained.  In practice, I suspect that we have
> > enough packages with problems here that you have to compute the dependency
> > closure anyway, but insofar as priorities are useful for anything, I think
> > that was the goal.
> 
> Calculating a dependency closure is neither an easy nor an task with
> a well-defined outcome. Starting with more data makes that both more
> easy and more likely to come to deterministic results (with a good
> enough starting set, most dependencies will most likely already be in
> that set, so the likelyhood to encounter virtual packages or or-ed
> dependencies (especially those were different packages have different
> first choices) is much smaller.
> 
> The difference between optional and extra is indeed mood today. But I
> guess that is mostly because dh_make is making everything optional
> instead of extra by default...

Uhm, I don't think that is the case; I, for one, have always adjusted
the priority of dh_make-generated packages to "optional" by hand :)

[r...@straylight ~]$ dpkg -L dh-make | perl -nle '-f and m{/control$} and 
print' | sort | xargs fgrep Priority
/usr/share/debhelper/dh_make/debianb/control:Priority: extra
/usr/share/debhelper/dh_make/debiani/control:Priority: extra
/usr/share/debhelper/dh_make/debiank/control:Priority: extra
/usr/share/debhelper/dh_make/debianl/control:Priority: extra
/usr/share/debhelper/dh_make/debianm/control:Priority: extra
/usr/share/debhelper/dh_make/debiann/control:Priority: extra
/usr/share/debhelper/dh_make/debians/control:Priority: extra
[r...@straylight ~]$

G'luck,
Peter

-- 
Peter Pentchev  r...@space.bgr...@ringlet.netr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
The rest of this sentence is written in Thailand, on


signature.asc
Description: Digital signature

Bug#589632: RFH: ppp -- Point-to-Point Protocol (PPP) - daemon

[Marco d'Itri]

Package: wnpp
Severity: normal

I request assistance with maintaining the ppp package.
The package is in an acceptable shape, but I need a lot of help with
bugs triaging and fixing.
The upstream maintainers are not exactly MIA, but they tend to ignore
patches and requests.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Priority dependence

[Bernhard R. Link]

* Peter Pentchev  [100719 13:10]:
> On Mon, Jul 19, 2010 at 12:41:54PM +0200, Bernhard R. Link wrote:
> > The difference between optional and extra is indeed mood today. But I
> > guess that is mostly because dh_make is making everything optional
> > instead of extra by default...
>
> Uhm, I don't think that is the case; I, for one, have always adjusted
> the priority of dh_make-generated packages to "optional" by hand :)

Looks like I am a bit out of date here. dh-make 0.42 changed it to
extra.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100719131903.ga8...@pcpool00.mathematik.uni-freiburg.de

Re: Bug#589342: ITP: sieve -- Extension that implements the ManageSieve protocol

[Michael Goetze]

Hi,

On 07/16/2010 09:44 PM, fladischermich...@fladi.at wrote:

* Package name: sieve
   Version : 0.1.9
   Upstream Author : Thomas Schmid
* URL : http://sieve.mozdev.org/
* License : AGPLv3
   Programming Lang: JavaScript, XUL
   Description : Extension that implements the ManageSieve protocol


May I suggest that this Package would be better named icedove-sieve? 
Failing that, at least the short description should say what it is an 
extension of.


Regards,
Michael


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c4477b7.6040...@mgoetze.net

Re: Priority dependence

[Ian Jackson]

Russ Allbery writes ("Re: Priority dependence"):
> * Essential-only, usually only desirable in cases like build chroots.
>   Doesn't use priority at all, but should just start from the essential
>   packages and compute a dependency closure.  This seems to be what the
>   intention of Priority: required was, but I'm not sure I see why we
>   should have required separate from Essential: yes plus dependencies.

At the time all this was invented we didn't have such sophisticated
automatic dependency calculators.  Also package turnover and number of
packets were much smaller, and dependency sets of base packages were
smaller.  So doing it manually was much less work.

> * Base installation.  The smallest possible installation you can put on a
>   regular system and have a working and usable text-mode computer on which
>   you can install other things and which looks like UNIX.  This seems to
>   be what Priority: important is supposed to give you.

Yes.

> * Standard installation.  This should be chosen explicitly for the
>   installer, really.  The difference between Priority: standard and
>   Priority: optional-or-extra would be whether we think it makes sense to
>   install that package in a default install.

Yes.

The priorities do provide assistance to dependency resolution.  That's
true of both automatic dependency resolvers, and humans who are
dealing with unfamiliar packages.

Perhaps the priorities should be calculated automatically by
transitive closure ?  That does risk the kind of spreading priority
escalation that the libboost-* aptitude thing demonstrates.

> The Policy language around this is written as if installing all of
> optional were a reasonable thing to do, which hasn't been the case for
> years.

I still think it would be useful for there to be a set of packages
which really is everything that you can sensibly install at once.  If
optional isn't that any more then perhaps we could do some autoinstall
testing to make sure that it is.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19524.32039.957789.93...@chiark.greenend.org.uk

Re: Priority dependence

[Ian Jackson]

Bernhard R. Link writes ("Re: Priority dependence"):
> Calculating a dependency closure is neither an easy nor an task with
> a well-defined outcome. Starting with more data makes that both more
> easy and more likely to come to deterministic results (with a good
> enough starting set, most dependencies will most likely already be in
> that set, so the likelyhood to encounter virtual packages or or-ed
> dependencies (especially those were different packages have different
> first choices) is much smaller.

In theory since it does not normally make sense to simultaneously
install two different packages to do the same thing in the same way
(two implementations of the same interface), any dependency
ambiguities should be resolvable by reference to which of the multiple
possibilities are extra and which are optional.  Only one should be
optional.

But we don't automatically check any of this so I guess it's unlikely
to be true.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19524.32255.306441.277...@chiark.greenend.org.uk

Re: packages being essential but having stuff in /usr/?!

[Tollef Fog Heen]

]] Patrick Schoenfeld 

| On Fri, Jul 16, 2010 at 07:30:17PM +0200, Christoph Anton Mitterer wrote:
| > What about /etc?
| 
| Well, this one is easy: /etc *can not* be on its own partition.
| It has to be on the root filesystem so it will be available.

Nah, it just has to be mounted when init is started.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkxnqsmc@qurzaw.linpro.no

Re: Bug#589342: ITP: sieve -- Extension that implements the ManageSieve protocol

[Michael Fladischer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Goetze, 2010-07-19 18:05:
> May I suggest that this Package would be better named icedove-sieve?

You are right, I already changed the name[1] of the source package to
icedove-sieve. The binary package will be xul-ext-sieve.

[1] http://git.debian.org/?p=pkg-mozext/icedove-sieve.git;a=summary

Regards,

- -- 
Michael Fladischer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxEiwsACgkQeJ3z1zFMUGbpUgCeJ6UyxguAaAtedvGI0RY2geJF
eqcAniw2sUbgFju/T/iJsurrt1iIXObJ
=G4D1
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c448b0c.2000...@fladi.at

Anyone collected historical data for popcons of derivative(s)?

[Yaroslav Halchenko]

Dear Fellows,

I wonder if anyone cron-ed fetching of popcons for derivative
distributions (e.g. Ubuntu).  ubuntu exposes only current status
http://popcon.ubuntu.com/ and I've not found if there is any way obtain
historical data (like we have one available for DDs).

I am asking because we thought to plot few plots for our debconf talk. 
UDD also seems to store only current status for popcons of both ubuntu
and Debian... So I thought that may be someone already did set up some
cron job to fetch Ubuntu popcons?  I found no official information on
Ubuntu popcon historical data being available, so decided to check with
you guys first before asking in the derivatives land.

thanks in advance for reply
-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]




signature.asc
Description: Digital signature

Re: Priority dependence

[Neil Williams]

On Sun, 18 Jul 2010 15:16:49 -0700
Russ Allbery  wrote:

apologies for this one being so long...

> Neil Williams  writes:
> 
> > It is very worthwhile having a clear division between Required and
> > Important. A typical bootstrap should include Required but there is
> > no need for any of the important packages and any which may be
> > useful can be added explicitly.
> 
> That's probably part of what I'm missing; what's the purpose of
> required in addition to essential plus dependencies?

Required provides a general-case base for many situations but even this
is too large a collection for some purposes. Required is a largely
complete set, it is hard to bring in more than about 30% of the
Required packages without bringing in the rest. Exceptions are probably
gcc-x.x-base, bash and dash or dash and bash, debconf (because cdebconf
should be possible instead) and e2fs* for SSD systems where ext* is a
waste of time.

Important adds nothing useful to that set - read as a *set* - although
it does contain *individual* packages that are useful to cherry-pick,
principally apt. 

A quick test gives Important as:

adduser  apt-utils  apt  aptitude  bsdmainutils  libbz2-1.0  cpio
cron  libcwidget3  debian-archive-keyring  dmidecode  libgdbm3  gnupg
gpgv  groff-base  ifupdown  iproute  iptables  iputils-ping
dhcp3-client  dhcp3-common  isc-dhcp-client  isc-dhcp-common
logrotate  libept1  libsigc++-2.0-0c2a  libtasn1-3  libusb-0.1-4
man-db  manpages  module-init-tools  nano  libncursesw5  net-tools
netbase  netcat-traditional  libnewt0.52  whiptail  libssl0.9.8
libpopt0  procps  libreadline5  libreadline6  readline-common  rsyslog
libslang2  tasksel-data  tasksel  libwrap0  info  install-info
traceroute  udev  vim-common  vim-tiny  wget  libxapian15

Of those, aptitude and it's dependencies are not necessary (just nice
to have sometimes), tasksel and dependencies should only be included
when using D-I, whiptail and readline (and dependencies) are not always
necessary, particularly when debconf is preset to non-interactive
(like chroots) and having both vim and nano is just overkill. I like vim
but even vim-tiny is not as small as it's name would indicate and yet
not sufficiently useful, compared to vim-full, to be retained on many
systems.

> Policy defines required as:
> 
> Packages which are necessary for the proper functioning of the
> system (usually, this means that dpkg functionality depends on these
> packages). Removing a required package may cause your system to
> become totally broken and you may not even be able to use dpkg to put
> things back, so only do so if you know what you are doing. Systems
> with only the required packages are probably unusable, but they do
> have enough functionality to allow the sysadmin to boot and install
> more software.

The only Important package which can be shoe-horned into such a
description is apt.

Required is reasonably OK at the moment, IMHO; the few packages that
are unwanted are not that large. Important is just too large a set and
contains packages that are simply not that "important" to everyone.

On a strict reading of the above, I would regard only those packages
utterly intrinsic to the unpacking of .deb files as Required - tar, ar,
and coreutils (or a modified busybox). (Yes, I have got into a situation
where a bootable system had no dpkg, no coreutils, no tar and no ar -
just a busybox shell - the unmodified busybox from DI. That led to a
reinstall. *That* is what I'd consider "totally broken".) ;-)

As a case in point, I think Policy 2.5 has this bit wrong:

"Systems with only the required packages are probably unusable, but they
do have enough functionality to allow the sysadmin to boot and install
more software."

Systems with only the required packages installed can be fully usable -
depending on the type of tasks expected of that system. The installed
packages still include enough functionality to allow the sysadmin to
boot and install more software.

I might even file a bug report against debian-policy for that one. It's
a subtle change but one that reflects the move towards making Debian a
truly Universal OS, not just a desktop and server OS (which, IMHO, it
was until, probably, Lenny).

> This sounds quite a bit like the definition of essential, except that
> required adds "allow the sysadmin to boot" and essential has the
> special unconfigured requirement.

 yet no kernel package is Priority: required - nor should one be,
even though it's not that common to boot a runtime system without a
local kernel. 

> Hm.  So are there packages that aren't usable until configured but
> which should never be removed from the system?  I guess that would be
> the difference between required and the essential closure.

Even dpkg can be removed from the system if the admin is sufficiently
careful and uses a static configuration. (See Emdebian Baked [0])

These divisions are arbitrary and have been traditionally decided on
the basis of our own desktop an

Re: Priority dependence

[Neil Williams]

On Mon, 19 Jul 2010 00:08:32 +0200
Michael Banck  wrote:

> On Sun, Jul 18, 2010 at 10:14:57PM +0100, Neil Williams wrote:
> > On Sun, 18 Jul 2010 11:04:10 -0700
> > Russ Allbery  wrote:
> > 
> > > Frans Pop  writes:
> > > 
> > > > Maybe we should consider changing the default prio for all
> > > > library packages to optional or lower, except for specific
> > > > cases (e.g. libc) where the lib itself can actually be
> > > > considered part of the core system.
> > > 
> > > I would make a stronger argument than that: how much do we care
> > > about any priorities other than important, standard, and
> > > everything else? 
> > 
> > It is very worthwhile having a clear division between Required and
> > Important. A typical bootstrap should include Required but there is
> > no need for any of the important packages 
> 
> If you want to have it minimal, install just the essential packages I
> think was Russ' point.  And/or possibly change/adjust essential so
> that it matches what you say is required above.

No, Essential has a different purpose (I've been picked up on this
issue before) - we need to be clear about Essential vs required.
Priority: required doesn't affect how other packages list their
own dependencies, Essential does.

Having said that, it is entirely possible to ignore Essential -
Emdebian has been doing that since before Lenny without any problems.
[0] It is even possible to ignore both Essential and Priority:
required, if you are sufficiently careful, because this brings
important benefits like being able to omit perl with just a suitably
modified busybox package and a narrow package set.

Essential doesn't matter when the user has no supported interface to
apt - as with many embedded uses of Debian.

[0] http://wiki.debian.org/EmdebianPolicy

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpO7Qn3kpB9B.pgp
Description: PGP signature

Bug#589675: ITP: mothur -- sequence analysis suite for research on microbiota

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: mothur
  Version : 1.11.0
* URL : http://www.mothur.org
* License : unclear
  Programming Lang: C
  Description : sequence analysis suite for research on microbiota

 Mothur seeks to develop a single piece of open-source, expandable
 software to fill the bioinformatics needs of the microbial ecology
 community. It has incorporated the functionality of dotur, sons,
 treeclimber, s-libshuff, unifrac, and much more. In addition to improving
 the flexibility of these algorithms, a number of other features including
 calculators and visualization tools were added.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100719211400.12924.60273.report...@toshiba.siemens

Re: Priority dependence

[brian m. carlson]

On Mon, Jul 19, 2010 at 09:14:52PM +0100, Neil Williams wrote:
> Of those, aptitude and it's dependencies are not necessary (just nice
> to have sometimes), tasksel and dependencies should only be included
> when using D-I, whiptail and readline (and dependencies) are not always
> necessary, particularly when debconf is preset to non-interactive
> (like chroots) and having both vim and nano is just overkill. I like vim
> but even vim-tiny is not as small as it's name would indicate and yet
> not sufficiently useful, compared to vim-full, to be retained on many
> systems.

The vi and nano debate was had a long time ago.  So was the nvi versus
vim-tiny.  It was decided that first-time users were not going to be
able to navigate vi, but experienced users would expect it.  I don't
know why people argued for vim-tiny over nvi; for a really rudimentary
base system, I think smaller is better.

> "Systems with only the required packages are probably unusable, but they
> do have enough functionality to allow the sysadmin to boot and install
> more software."
> 
> Systems with only the required packages installed can be fully usable -
> depending on the type of tasks expected of that system. The installed
> packages still include enough functionality to allow the sysadmin to
> boot and install more software.

I think the key word here is "probably".  For many purposes, such a
system is completely unusable.  For example, required contains no text
editor.  My cell phone (running Android 1.6) has no need for a text
editor, and therefore doesn't have one.  However, any machine on which
I'm personally going to install Debian is certainly going to need one
out of the box, and so required is insufficient.

> I might even file a bug report against debian-policy for that one. It's
> a subtle change but one that reflects the move towards making Debian a
> truly Universal OS, not just a desktop and server OS (which, IMHO, it
> was until, probably, Lenny).

I think that Debian is a good base for a variety of systems, but that
it's simply not feasible to make it suitable for very, very small
embedded systems as well as normal laptops, desktops, and servers.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Priority dependence

[Russ Allbery]

"brian m. carlson"  writes:

> The vi and nano debate was had a long time ago.  So was the nvi versus
> vim-tiny.  It was decided that first-time users were not going to be
> able to navigate vi, but experienced users would expect it.  I don't
> know why people argued for vim-tiny over nvi; for a really rudimentary
> base system, I think smaller is better.

There was a long argument at the time which mostly amounted to, if I
remember correctly, vim having a more active upstream.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj97nih7@windlord.stanford.edu

vim-tiny in base (was Re: Priority dependence)

[James Vega]

On Mon, Jul 19, 2010 at 04:45:56PM -0700, Russ Allbery wrote:
> "brian m. carlson"  writes:
> 
> > The vi and nano debate was had a long time ago.  So was the nvi versus
> > vim-tiny.  It was decided that first-time users were not going to be
> > able to navigate vi, but experienced users would expect it.  I don't
> > know why people argued for vim-tiny over nvi; for a really rudimentary
> > base system, I think smaller is better.
> 
> There was a long argument at the time which mostly amounted to, if I
> remember correctly, vim having a more active upstream.

FWIW, if I knew then all the issues that I've had to deal with from that
change (primarily very confused users, but also hassling with diversions
under a versioned directory and having to carry a non-upstreamable
patch), I probably would've argued against the change among my fellow
Vim maintainers.  I think the vim-tiny package has ended up being more
work than it's worth.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: Xen for Squeeze, 3.4 or 4.0

[Russell Coker]

On Mon, 19 Jul 2010, Toni Mueller  wrote:
> On Thu, 10.06.2010 at 17:54:28 +0200, Bastian Blank  
wrote:
> > My personal preference would be to go with 4.0.
> 
> If it's one, then I opt for 4.0.

I've got a few systems running Xen 4.0 now.  It's working pretty well.

I've got one system where the latest version of GRUB won't boot Xen 4.0, but 
apart from that it seems fine.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007201124.12893.russ...@coker.com.au

Re: Priority dependence

[Romain Beauxis]

Hi !

Le dimanche 18 juillet 2010 13:41:10, vous avez écrit :
> Something to consider for Squeeze + 1?

Agreed. Just like you it seems at some point the installation would use tools 
like dpkg and install according to the priority.

Nowadays, a clear setting where we select the tip of the iceberg and let the 
rest being pulled according to the actual dependencies.

This would have the advantage of being much more readable and would avoid a 
lot of extra (optional ?) complications which bring a dependency to the same 
semantics level as a package that really is required/important..


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201007192225.31783.to...@rastageeks.org