Re: Debian default desktop environment

[Wolodja Wentland]

On Sat, Apr 05, 2014 at 12:55 +0800, Thomas Goirand wrote:
> On 04/04/2014 09:55 PM, Undefined User wrote:
> > 2014-04-04 10:52 GMT-03:00 Jonathan Dowland  > >:
> > 
> > We go over the same ground over and over. I'm increasingly in favour
> > of *no*
> > default. You must pick one from a list on install. Randomize the list if
> > necessary.
> > Perfect solution.
> > 
> > Debian installer should provide you information about desktop
> > environments and let the user choose it.
> 
> There's only one problem with this approach: somebody has to actually
> implement it... [1]

> [1] And it's been years we're (uselessly) discussing it.

Yes, that is in fact the real problem thank you for stating that so
succinctly.

But wouldn't a nicer menu in the graphical installer with pictures or even
videos and a little text in both versions be worth it? If so then we have at
least an ideal to aspire to (even though nobody implements it) and if not
then we can move on.
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Debian default desktop environment

[Jakub Wilk]

* Gunnar Wolf , 2014-04-04, 23:22:

- Media player: mplayer (on libcaca, of course)


With its 4 RC bugs, it doesn't look like mplayer is going to be part of 
jessie.


--
Jakub Wilk


--
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/20140405075710.gb3...@jwilk.net

Re: Debian default desktop environment

[Iain R. Learmonth]

On 05/04/14 06:22, Gunnar Wolf wrote:
> So, I suggest we ship a desktop consisting of:
> 
> - Window manager: i3
> - File browser: urxvt
> - Photo viewer: caca-utils
> - Web browser: lynx
> - Mail client: mutt
> - Instant messenger: irssi
> - Productivity suite: emacs
> - Music app: supercollider
> - Media player: mplayer (on libcaca, of course)
> 

Whilst that is basically my setup, it is definitely not an intuitive one
to use.

For power users, it likely is better than GNOME, KDE, etc. but it's only
power users that would take the time to get acquainted with it.

If someone wanted to put together a meta-package and some scripts for
tighter integration however, I would be very happy to test it, and
wouldn't mind seeing an installer that uses it as default, but it
shouldn't be *the* default.

Iain.

-- 
urn:x-human:Iain R. Learmonth
http://iain.learmonth.me/
mailto:i...@fsfe.org
xmpp:i...@jabber.fsfe.org
tel:+447875886930

GPG Fingerprint: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49
Please verify out-of-band before trusting with sensitive information.

[[[ To any GCHQ or other security service agents reading my email: ]]]
[[[ Please consider if any professional body code of conduct to]]]
[[[ which you subscribe requires you to follow Snowden's example.  ]]]
[[[ Your professional membership, chartered or incorporated status ]]]
[[[ may be at risk.]]]



signature.asc
Description: OpenPGP digital signature

Re: Debian default desktop environment

[Milan Zamazal]

> "JM" == Josselin Mouette  writes:

JM> This is mostly irrelevant. The resources consumed by the desktop
JM> are negligible compared to applications. As soon as you start a
JM> browser with a few tabs on non-trivial websites, 1 GiB of memory
JM> is barely enough.  Regardless of the desktop environment.

FYI, Xfce + Firefox runs fine on a >10 years old computer with 256 MB
RAM for all practical needs of the user.



-- 
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/87ha682jge@blackbird.zamazal.org

Bug#743710: ITP: mlpack -- Fast and scalable C++ machine learning library

[Barak A. Pearlmutter]

Package: wnpp
Owner: Barak A. Pearlmutter 
Severity: wishlist

Package name: mlpack
Version : 1.0.8
Upstream Author : Ryan Curtin 
URL or Web page : http://www.mlpack.org/
License : LGPL-3+
Description : Fast and scalable C++ machine learning library

MLPACK (Machine Learning PACK) is an intuitive, fast, and scalable C++
machine learning library, meant to be a machine learning analog to
LAPACK.  It aims to implement a wide array of machine learning methods
and function as a "swiss army knife" for machine learning researchers.

Upstream has been notified of this ITP, and is encouraging.

For a preliminary packaging, see
 git://anonscm.debian.org/debian-science/packages/mlpack.git

Most of the lintian issues are due to doxygen generating bogus man
pages.  Excepting those, I'd hope to either address or report the issues
to upstream for most of the others before uploading.

--Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
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/87bnwgylgi@dellarge.hamilton.ie

Re: Deprecating/removing racoon/ipsec-tools from Debian GNU/Linux and racoon from Debian/kfreebsd

[Christian Hofstaedtler]

* Noah Meyerhans  [140405 00:06]:
> On Fri, Apr 04, 2014 at 12:59:35PM +1300, Matt Grant wrote:
> > 4) racoon/setkey are native IPSEC implementations across FreeBSD,
> > NetBSD, Mac OSX, and Linux, and thus having it available give a 'just
> > works' IPSEC option. 

I must also add that "it really just works". In particular,
roadwarrior server-side setups are really easy to setup nowadays and
work very well.

> > My main concern as maintainer are the security issues, with an old code
> > base running as root.
> 
> The code base may be old, but it's pretty widely used and thus should
> have many eyes watching it. (I'm being optimistic, I know). The
> ipsec-tools mailing lists don't see a lot of activity, but they're by no
> means dead.  And there was just an upstream 0.8.2 release in February.

Can't really comment on security of an maybe old code base here, but
I had the feeling that at least Openswan was "more dead" than
racoon.

> > I am willing to co-maintain this package with other developers and
> > maintainers.  My belief is that there is likely a Debian kFreeBSD
> > developer/maintainer out there who would like to do this, and do a lot
> > of the work :-)
> 
> I'm happy to help maintain ipsec-tools, as I make regular use of it and
> have done so for several years. I'd also be supportive of removing it
> for jessie+1 based on your arguments for doing so. If that's the path
> taken, it'd be really good if we could document (and at least partially
> automate?) the migration path from racoon to the preferred alternatives.

I have no clue of kFreeBSD, but I'm using racoon on Linux. I'd offer
help if the goal would be to keep racoon.

  -ch

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: Digital signature

Re: Debian default desktop environment

[Josselin Mouette]

Le samedi 05 avril 2014 à 11:50 +0200, Milan Zamazal a écrit :
> FYI, Xfce + Firefox runs fine on a >10 years old computer with 256 MB
> RAM for all practical needs of the user.

Well, I guess our “practical needs” differ. Heavily.

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1396719888.4331.42.ca...@kagura.malsain.org

Re: Debian default desktop environment

[Josselin Mouette]

Le vendredi 04 avril 2014 à 23:52 +0100, Philip Hands a écrit :
> Anyway, to return to the main point, I do wonder why nobody has bothered
> to mention that the reason for the switch was that Gnome no longer fits
> on CD#1.

The thing that I don’t understand is that someone made such a decision,
which is a *functional* one, based on a purely *technical* matter.
Especially one as minor as the installation CD which has no actual
conceivable use today.

There are valid arguments for picking either of KDE, Xfce or GNOME. But
if the main reason for choice is a vague “fits on CD#1” requirement,
then I’m afraid we lack precise technical requirements of what changes
need to be implemented.

> Actually, no, instead why don't you all check out the various threads on
> debian-boot where those arguments have failed to be persuasive, and then
> go and do something productive instead.

Could you please sum up those discussions and explain what kind of
changes you would consider to be productive? 

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1396720670.4331.48.ca...@kagura.malsain.org

Re: Debian default desktop environment

[brian m. carlson]

On Sat, Apr 05, 2014 at 07:57:50PM +0200, Josselin Mouette wrote:
> Could you please sum up those discussions and explain what kind of
> changes you would consider to be productive?

I can sum up the discussions that were had last time on debian-devel for
you, at least as I remember them.

* XFCE fits on one installation CD, which is relevant for those people
  who have slow or expensive Internet access (which is many parts of the
  developing world).  The older machines which may be more likely to be
  in use in those areas may not have a DVD drive, or downloading 4 GB
  for a DVD may be prohibitive in time or cost.
* It works better on older and less powerful machines[0].
* Some people claim that the interface is more familiar for
  non-technical people coming from other operating systems.  This is the
  subject of much debate, however.
* Similarly, some people dislike the GNOME shell interface and prefer a
  more traditional desktop environment[1].
* There were concerns about accessibility support, "particularly for the
  blind"[2].

[0] I have personally found this to be the case.  I've had older
machines where GNOME simply took up too many resources and was sluggish,
but XFCE ran fine.
[1] The very existence of MATE provides some support for this argument,
at least.
[2] 
http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=dfca406eb694e0ac00ea04b12fc912237e01c9b5
-- 
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

Does partial upgrade between stable and testing must be supported ?

[Vincent Danjean]

  Hi everybody,

  In #704805, there is a disagreement between the maintainer of R software
and several other people (me included).

  R software is packaged into a lots of different Debian packages (with
different maintainers) along with the main R package (r-base-core).
Due to internal changes, the r-base-core in testing (currently 3.0.3-1)
does not work with lots of r packages in stable (compiled with
the r-base-core of stable, ie 2.15.1-4).
  I think that everybody (bug submitters and maintainer) agree with that.

  The disagreement comes from the fact that the maintainer does not
think that he must declare this incompatibility.
  For now, if you install a r package from testing, it will pull
the r-base-core from testing (due to dependency such as
"Depends: r-base-core (>= 3.0.2-1)")
  But, when r-base-core from testing is installed, the system keeps
other r related packages from stable (no conflict, break, ...)
and these packages won't work anymore.

  The maintainer think that he does not need to do anything about
that. People should just upgrade all their packages from stable to
testing when r-base-core is upgraded.
  Other people (and me) disagree and think that other broken r-related
packages must be either removed or upgraded automatically by apt
when r-base-core is upgraded (due to additional conflicts/breaks/...
declarations)

On 05/04/2014 15:16, Dirk Eddelbuettel wrote:
> |   Currently, R is unusable with partial upgrade between stable and
> | testing. However, this is something that we must support (and that have
> | a severity above normal)
> 
> Not ideal but I don't think that partially upgrades between stable and
> testing are a goal of the project or distribution. The goal is to get testing
> where we can cut a new stable. If current testing works...

  I'm interested by having more inputs on this point, hence my mail
to d-d.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/534057bd.6040...@free.fr

Re: Does partial upgrade between stable and testing must be supported ?

[Sune Vuorela]

On 2014-04-05, Vincent Danjean  wrote:
>   The maintainer think that he does not need to do anything about
> that. People should just upgrade all their packages from stable to
> testing when r-base-core is upgraded.
>   Other people (and me) disagree and think that other broken r-related
> packages must be either removed or upgraded automatically by apt
> when r-base-core is upgraded (due to additional conflicts/breaks/...
> declarations)

I agree with you and other people. partial upgrade should work.
Requiring packages to be uninstalled is a great way of ensuring that
partial upgrades works.

/Sune


-- 
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/lhpm81$eti$1...@ger.gmane.org

Re: Does partial upgrade between stable and testing must be supported ?

[Matthias Urlichs]

Hi,
>   The maintainer think that he does not need to do anything about
> that. People should just upgrade all their packages from stable to
> testing when r-base-core is upgraded.
>   Other people (and me) disagree and think that other broken r-related
> packages must be either removed or upgraded automatically by apt
> when r-base-core is upgraded (due to additional conflicts/breaks/...
> declarations)

"Pull this package from Testing because it has feature X which I need",
while keeping the rest of the system on Stable, is a common use case.

Upgrading a single package should not cause a regression.
This is why we have a package management system with dependencies
(both positive and negative) in the first place!

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Debian default desktop environment

[Matthias Klumpp]

2014-04-05 20:18 GMT+02:00 brian m. carlson :
> On Sat, Apr 05, 2014 at 07:57:50PM +0200, Josselin Mouette wrote:
>> Could you please sum up those discussions and explain what kind of
>> changes you would consider to be productive?
>
> I can sum up the discussions that were had last time on debian-devel for
> you, at least as I remember them.
>
> * XFCE fits on one installation CD, which is relevant for those people
>   who have slow or expensive Internet access (which is many parts of the
>   developing world).  The older machines which may be more likely to be
>   in use in those areas may not have a DVD drive, or downloading 4 GB
>   for a DVD may be prohibitive in time or cost.
> * It works better on older and less powerful machines[0].
> * Some people claim that the interface is more familiar for
>   non-technical people coming from other operating systems.  This is the
>   subject of much debate, however.
> * Similarly, some people dislike the GNOME shell interface and prefer a
>   more traditional desktop environment[1].
> * There were concerns about accessibility support, "particularly for the
>   blind"[2].
> [...]
Those aren't "solid" arguments...
Replace "Xfce" with $anydesktop and you will get the same result. MATE
is not an argument for the vague "some people dislike GNOME-Shell"
(who is some people? why are they more important than the ones who
like the GNOME-Shell?) - some people didn't like KDE so they started
Trinity, so you could use the same argument there.
GNOME could be made to fit on CD1 (we use stronger compression now and
could leave out some components)[1].
For the accessibility stuff, I would say GNOME offers one of the best
experiences - and I say that as KDE user and developer.
So, we need other arguments to switch to GNOME/Xfce/KDE as default
than that ones.
Cheers,
Matthias

[1]: Personally, I think we should offer a DVD instead of a CD as
primary installation medium. A CD could still be optional, offering a
installation media with reduced components (e.g. no LibreOffice by
default) for those who need/want it.

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny-V5zoKdb=sr+j559jbyx2wza5gys5xywoy56nczun...@mail.gmail.com

Re: Debian default desktop environment

[Ben Hutchings]

On Sat, 2014-04-05 at 18:18 +, brian m. carlson wrote:
> On Sat, Apr 05, 2014 at 07:57:50PM +0200, Josselin Mouette wrote:
> > Could you please sum up those discussions and explain what kind of
> > changes you would consider to be productive?
> 
> I can sum up the discussions that were had last time on debian-devel for
> you, at least as I remember them.
> 
> * XFCE fits on one installation CD, which is relevant for those people
>   who have slow or expensive Internet access (which is many parts of the
>   developing world).  The older machines which may be more likely to be
>   in use in those areas may not have a DVD drive, or downloading 4 GB
>   for a DVD may be prohibitive in time or cost.
> * It works better on older and less powerful machines[0].

Those are good arguments for providing an Xfce CD - as we have done in
previous releases - but not that it should be the recommended
installation image in general.

[...]
> * There were concerns about accessibility support, "particularly for the
>   blind"[2].
[...]

Which is unfortunately quite bad in most free graphical desktop
environments.  Is it actually a strength of Xfce?  I didn't think it
was.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


signature.asc
Description: This is a digitally signed message part

Re: Debian default desktop environment

[brian m. carlson]

On Sat, Apr 05, 2014 at 11:32:07PM +0100, Ben Hutchings wrote:
> On Sat, 2014-04-05 at 18:18 +, brian m. carlson wrote:
> [...]
> > * There were concerns about accessibility support, "particularly for the
> >   blind"[2].
> [...]
> 
> Which is unfortunately quite bad in most free graphical desktop
> environments.  Is it actually a strength of Xfce?  I didn't think it
> was.

I just realized my statement was unclear.  I believe some people had
stated that GNOME had regressed in accessibility support at the time,
and XFCE was a better choice in this regard.  I can't say more because I
don't have enough knowledge on the subject.  Maybe someone else can.

-- 
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: Debian default desktop environment

[Cyril Brulebois]

brian m. carlson  (2014-04-05):
> I just realized my statement was unclear.  I believe some people had
> stated that GNOME had regressed in accessibility support at the time,
> and XFCE was a better choice in this regard.  I can't say more because I
> don't have enough knowledge on the subject.  Maybe someone else can.

Until a few weeks before the wheezy release, we had troubles with gdm3.
Most of that was fixed by Emilio, mainly in that upload AFAICT from a
(very) quick look:
  http://packages.qa.debian.org/g/gdm3/news/20130410T130254Z.html

I don't think Xfce has better a11y support than Gnome. It actually lacks
some integration (see errata for D-I Jessie Alpha 1); I haven't been
able to work on/check approaches suggested on -a11y@ yet.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Does partial upgrade between stable and testing must be supported ?

[James McCoy]

On Sat, Apr 05, 2014 at 07:40:49PM +, Sune Vuorela wrote:
> On 2014-04-05, Vincent Danjean  wrote:
> >   The maintainer think that he does not need to do anything about
> > that. People should just upgrade all their packages from stable to
> > testing when r-base-core is upgraded.
> >   Other people (and me) disagree and think that other broken r-related
> > packages must be either removed or upgraded automatically by apt
> > when r-base-core is upgraded (due to additional conflicts/breaks/...
> > declarations)
> 
> I agree with you and other people. partial upgrade should work.
> Requiring packages to be uninstalled is a great way of ensuring that
> partial upgrades works.

There was a similar discussion a year ago[0] where it was suggested that
a core r package should provide a virtual package, similar to
perlapi-5.18.1.  Then some build helper should ensure that gets added to
the Depends of relevant packages through some substvar (likely
${R:Depends}).

[0]: http://lists.debian.org/87bo9ztrww@deep-thought.43-1.org

Apparently, there hasn't been any action in that direction.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


-- 
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/20140405233748.gg2...@jamessan.com

Bug#743753: ITP: python-posix-ipc -- semaphores, shared memory and message queues

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-posix-ipc
  Version : 0.9.8
  Upstream Author : Philip Semanchuk 
* URL : http://semanchuk.com/philip/posix_ipc/
* License : BSD-3-clause
  Programming Lang: Python
  Description : semaphores, shared memory and message queues

 posix_ipc is a Python module (written in C) that permits creation and
 manipulation of POSIX inter-process semaphores, shared memory and message
 queues on platforms supporting the POSIX Realtime Extensions a.k.a. POSIX
 1003.1b-1993. This includes nearly all Unices and Windows + Cygwin 1.7.

Note: This package is a new dependency of Tuskar, which is already in
Debian Experimental.


-- 
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/20140406010056.23682.40747.report...@buzig.gplhost.com

Re: Does partial upgrade between stable and testing must be supported ?

[Lisandro Damián Nicanor Pérez Meyer]

Hi Dirk, Charles and everybody!

I was going to share my current and very positive experience with Qt5 
providing a virtual package as Charles suggest, but looking further in the bug 
log I see that at least Scott and Don have already done so with other 
examples.

So just allow me Dirk to tell you that, in my experience, it's just a very 
nice tool to keep things coherent, even if you don't need to change it much.

Kinds regards, Lisandro.

-- 
Videogames do not influence kids. I mean, if Pac-Man influenced our
generation, we would all be jumping in dark rooms, chomping magic pills
and listening to electronic repeating music.
  Kristian Wilson, Nintendo Inc. 1989

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Submitted application/vnd.debian.binary-package to the IANA.

[Charles Plessy]

Hello everybody,

I eventually submitted the media type application/vnd.debian.binary-package to
the IANA via their on-line form , see
below for details.

Have a nice week-end,

-- Charles

- Forwarded message from IANA MIME Requests via RT  
-

Date: Sun, 6 Apr 2014 05:14:41 +
From: IANA MIME Requests via RT 
To: ple...@debian.org
Subject: [IANA #754162] AutoReply: Request for MIME media type 
Application/Vendor Tree -
vnd.
Reply-To: iana-m...@iana.org
Message-ID: 

To whom it may concern:

This is an automatically generated message to notify you that we have
received your request, and it has been recorded in our ticketing
system with a reference number of 754162. To check the status
of your request, please see:

https://tools.iana.org/ticket-status/app

If you have any problems accessing this page, please contact
i...@iana.org.

There is no need to reply to this message right now. IANA staff will
review your message shortly.

If this message is in reply to a previously submitted ticket, it is 
possible that the previous ticket has been marked as closed. As we 
review this ticket, we will also review previous correspondence and 
take appropriate action.

To expedite processing, and ensure our staff can view the full history 
of this request, please make sure you include the follow exact text in
the subject line of all future correspondence on this issue:

 [IANA #754162]

You can also simply reply to this message, as this tag is already in 
the subject line.

Thank you,

The Internet Assigned Numbers Authority
iana-m...@iana.org

-

Name : Charles Plessy

Email : ple...@debian.org

MIME media type name : Application

MIME subtype name : Vendor Tree - vnd.debian.binary-package

Required parameters : None.

Optional parameters : 
None.

Encoding considerations : binary


Security considerations : 
Debian binary packages can contain scripts executing arbitrary commands during
installation, which is done with administrator privileges.  It is therefore
essential to trust the origin of the package.  The recommended way is to
download packages from Debian format repositories that are authenticated with a
trusted cryptographic key (see the manual page of apt-secure for details).  As
a lesser alternative for cases where secure package manager frontends (such as
APT, cupt, etc.) are not available, the package should be downloaded with
secured protocols such as HTTPS.  There also exists a mechanism for signing
packages directly (called ‘debsigs’), but it is not deployed.

The Debian binary package consists of an ‘ar’ archive (in old common format)
containing, amongst other things, compressed tar archives for the primary
package contents such as the files to be installed (see the ‘deb’ manual page
for details on the format); it is therefore possible to inspect them with
standard UNIX tools (although the recommended way is through the command
‘dpkg-deb’) without actually installing the package and therefore without
executing the package's scripts.  An estimate of the uncompressed size of the
package may be available in its ‘control’ file, but it can only be trusted if
the package itself is trusted (a malicious person can design a package
containing small compressed files that become extremely large after
decompression).

Since the Debian packages convey programs to be installed on a computer,
the monitoring of a user's downloads over non-secured transport protocols such
as HTTP or FTP may reveal information pertaining to the user's privacy, or
suggest information related to the system's security such as the precise
version numbers of programs in use.

Interoperability considerations : 
Arbitrary Debian binary packages can be installed on any system where the
‘dpkg’ package manager is used, but it is recommended to only install packages
that have been built for a release matching the distribution installed on the
system.

Published specification : 
http://manpages.debian.org/cgi-bin/man.cgi?query=deb&manpath=Debian+unstable+sid

Applications which use this media : 
The Debian binary packages are manipulated by system programs such as ‘dpkg’,
‘apt-get’, graphical front-ends such as ’Synaptic’ but also generic archive
decompressors such as ‘File Roller’.  After downloading a package with a web
browser or after clicking on its icon, front-ends or decompressors are usually
started.

Fragment identifier considerations :
None.

Restrictions on usage :
None.

Provisional registration? (standards tree only) :
Not applicable


Additional information :

1. Deprecated alias names for this type : application/x-debian-package, 
application/x-deb
2. Magic number(s) : Version 2.0 files start with: !\ndebian-binary
3. File extension(s) : deb, udeb
4. Macintosh file type code : None.
5. Object Identifiers: None.



Person to contact for further information :

1. Name : The Debian Policy mailing list