Re: Depends/Recommends from libraries

[Marvin Renich]

* Simon McVittie <s...@debian.org> [170310 05:17]:
> On Thu, 09 Mar 2017 at 17:52:05 -0500, Marvin Renich wrote:
> > If more upstreams were careful to use dynamic loading in these
> > situations, it would be less of a problem.  In a perfect world, the
> > solution would be for foo's maintainer to convince upstream to switch to
> > dynamic loading.
> 
> (For context, I maintain several game engines that default to dlopen()ing
> their dependencies, some of which I have patched to stop doing that.)
> 
> I do not agree that dlopen()ing dependencies (what you have called "dynamic
> loading") is something we should encourage over normal linking with -lfoo
> (resulting in a DT_NEEDED entry, what you have called "static loading").

I'm sorry if I wasn't clear.  By "in these situations" I meant when the
library is only being used for a feature that is not likely to be used
by most users of the package, and only when the library has additional
dependencies that the user may want to avoid if he does not want the
feature provided by the library.

> Having done that, either the plugin can either be split out into its own
> package that is recommended or suggested by the main package (as was done
> for gnome-software support for Flatpak), or the plugin's dependencies can
> be downgraded to Recommends or Suggests with something like
> "dh_shlibdeps -- -e/usr/lib/myplugins/myplugin.so -dRecommends" and it
> will fail to dlopen if they are missing (as is done in at least iproute2 and
> thunar, see https://codesearch.debian.net/search?q=-dRecommends).

I believe I was suggesting something along those lines...

> If a library dependency is sufficiently "heavy" that it needs to become
> optional, please consider that approach.

...and only in this specific case.

...Marvin

Re: Depends/Recommends from libraries

[Marvin Renich]

* Russ Allbery  [170309 13:19]:
> I think this would be a great way of introducing spurious bugs in our
> distribution from people who don't happen to read the README file and miss
> dependencies they actually need...

I think you are missing Ian's meaning.  Currently foo Depends libbar,
and libbar Depends bar-daemon.  If libbar were dynamically loaded, the
maintainer of foo would have used either a Recommends or Suggests for
libbar, but must instead use Depends because it is statically loaded.
If libbar-dev documents that it requires bar-daemon (and under what
circumstances, if appropriate), but libbar does not declare the Depends,
then it becomes the Debian maintainer of foo who decides to add an
appropriate Depends, Recommends, or Suggests for bar-daemon, in addition
to the Depends (that should be, but can't be, a Recommends or Suggests)
on libbar.  This is not pushed to the user at all, except in the normal
way that a user currently chooses to install Recommends or Suggests in
other circumstances.

Every Debian maintainer whose package links libbar would then be
required to read the documentation of libbar-dev, and act on that to add
a dependency that libbar would have used.  I would certainly expect a
Debian maintainer to read said documentation (irregardless of Ian's
proposal).  This has nothing to do with an end user reading a README
file to get the dependencies right (at least not any differently than
the current situation for other non-lib Recommends or Suggests).

I have not decided which side of the fence I am on, but I am certainly
empathetic to Ian's, Adam's, and others' desire to improve the
situation, as I have been bitten by this myself on more than one
occasion.  This is a situation where the maintainer of foo has no choice
but to use Depends, even if the library "can perhaps enhance [foo's]
usefulness, but installing [foo] without [libbar] is perfectly
reasonable."  You end up with a daemon that you don't want because
libbar Depends bar-daemon is appropriate, even if you, the end user, are
never going to use foo in a way that uses the libbar functionality.

If more upstreams were careful to use dynamic loading in these
situations, it would be less of a problem.  In a perfect world, the
solution would be for foo's maintainer to convince upstream to switch to
dynamic loading.  I'm not convinced that Ian's proposal is the right
approach, but I definitely agree that it is an attempt to solve a real
problem, and I believe it has more merit than you give it.

...Marvin

Re: node-tty-browserify_0.0.0-1_amd64.changes REJECTED

[Marvin Renich]

* Vincent Bernat  [170209 16:54]:
> Browserify takes code from npm (targetted at Node) and makes it run
> in the browser. Node comes with an API of its own that is not available
> in browsers. Browserify provides this code. There is nothing to patch
> since browserify is not a direct user of this code. It exposes it to
> modules that are unaware they are running in a browser.

If, as you describe, these small, do-nothing packages are not what node
uses when _not_ being run with browserify, but are just stubs
specifically for browserify, than a much better solution would be to
provide one package, browserify-dummy-stubs, have browserify depend on
that, and place all the stubs there.  Since, as Pirate Praveen says,

* Pirate Praveen  [170209 11:49]:
> We are not expecting anyone to install this module directly.

there is no reason to have a separate Debian package for each of these.
The excuse that the multitude of node packages have different update
cycles, so they should be in separate packages, is a complete
non-sequitur for a bunch of one- or two-line stubs that aren't going to
get any maintenance anyway.

...Marvin

Re: More 5 november in the release schedule

[Marvin Renich]

* Emilio Pozuelo Monfort  [161108 16:01]:
> It is true for other removals from testing, which can happen in two different 
> ways:
> 
> - The package was removed from unstable
> - The package was hinted for testing removal by the release team
> 
> Since britney doesn't enforce (atm) that build-dependencies are satisfiable in
> testing, those two cases can cause this problem. However in the former case,
> rdeps should get a FTBFS bug so you will know about the problem, and the 
> latter
> is not very frequent.

But wouldn't the FTBFS bug be filed after the removal of the build-dep,
so that it is too late for the maintainer to assist in keeping the
build-dep in the archive?  I thought this part of the thread was about
getting notification of pending, not already happened, removals so that
help could be directed in time to keep the package in the archive.  Do I
misunderstand?

...Marvin

Re: Bug#837606: general: system freeze

[Marvin Renich]

[Please do not CC me, I am subscribed.  You seem to have a habit of
CC'ing the individuals to whose messages you are responding.  This is
contrary to this list's documented policy.]

* Abou Al Montacir  [160914 05:31]:
> The duty of the project is to
> help him investigating the right way so that the bug get solved. Not saying 
> ask
> the community.

No, the project has no such duty.  This is a volunteer project, and the
software is both free and without any warranty.  Your whole tirade on
this thread appears to take the attitude that not only are you paying
the project for the software, but you are also paying for support.

You have no _right_ to expect any response at all to a bug report.
Fortunately, the members of the Debian project _want_ to make it better,
so they do pay attention to reported bugs.  Note that the first response
to the bug submitter was a very detailed description of things he could
do to begin narrowing down the problem (this has been pointed out to you
before).

However, if a bug report does not give any information that allows a
maintainer to determine the cause of the bug, or even what piece of
software has the bug, it absolutely is appropriate for the maintainer to
ask the bug reporter to "ask the community" for help in narrowing down
the cause of the bug, even to the point of closing the original bug and
asking the reporter to submit a new, more specific, bug after further
investigation.

In this case, nothing in the bug report gives any indication whether the
problem is due to software or hardware.  A low-RAM/high-swap situation
can also give symptoms similar to these, and in that case the OS is
behaving as expected.

The Debian Bug Tracking System is not a user support forum.  On the page
describing how to report bugs[1], it says

  If you are unable to determine which package your bug report should be
  filed against, please send e-mail to the Debian user mailing list
  asking for advice.

If you want a bug fixed, treat the maintainers as if they are doing you
a personal favor, because they are!  They are under no obligation to you
whatsoever.

...Marvin

[1] https://www.debian.org/Bugs/Reporting

Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Marvin Renich]

* Simon McVittie  [160727 20:04]:
> On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote:
> > Shouldn't this
> > dependency only be declared at some other level (libdbus, GDBus,...)?
> 
> I think this would have to be a new dbus-session metapackage, unless
> I'm missing something. dbus is the wrong place, and so are all the
> obvious libraries.

Do you mean metapackage or virtual package?  Wouldn't a virtual package
be exactly the right thing for this?  Then dbus-user-session and
dbus-x11 would each "Provides: dbus-session" and no additional real
package is required.  Maybe I do not understand what is being suggested.

...Marvin

preferred form for modification (was: Bug#817092: this browserified)

[Marvin Renich]

[please do not CC me]

* Ian Jackson <ijack...@chiark.greenend.org.uk> [160711 11:17]:
> Marvin Renich writes ("Re: [Pkg-javascript-devel] Bug#817092:  Bug#817092: 
> this browserified"):
> > One fundamental purpose...
> 
> I have no idea why you think this is relevant.

I apologize for not changing to subject to make it clear that I am not
in disagreement with the general discussion about this bug nor am I in
disagreement that the original source used to generate the
"browserified" file (along with the program used to generate it) must be
in Debian.  My point was that I disagreed with the general application
of one specific statement made by Jonas.

Upon re-reading Jonas' statement, it has become clear to me that he was
discussing what Debian is willing to distribute, not what the license
says Debian is allowed to distribute.  Jonas, I apologize for
misconstruing your meaning, and I retract my objection to your statement
in this context.  This distinction is important, and I should have seen
it in that message.

My message was triggered by the phrasing of Jonas' statement that was
very similar to past discussions over the meaning of "preferred form for
modification", especially in the context of the GPL.  In these
discussions it is sometimes asserted that, for purposes of the GPL and
other similar licenses, the phrase must be interpreted in terms of
upstream's preferred form.  However, neither the GPL itself, nor GNU's
published philosophy[1] support this; rather they contradict this
interpretation.  That part of the GPL is entirely about what a recipient
must give to a second level recipient.  Nowhere does the GPL mention
anything about giving changes back to upstream.

...Marvin

[1] https://www.gnu.org/philosophy/free-sw.html

Re: [Pkg-javascript-devel] Bug#817092: Bug#817092: this browserified

[Marvin Renich]

* Ian Jackson <ijack...@chiark.greenend.org.uk> [160711 08:59]:
> Marvin Renich writes ("Re: [Pkg-javascript-devel] Bug#817092:  Bug#817092: 
> this browserified"):
> > I have to disagree with this. The requirement for "preferred form of
> > modification" was explicitly to allow the recipient of the software the
> > freedom and ability to modify the software, not to force a particular
> > workflow (e.g. upstream's workflow) on the recipient, or require the
> > recipient to send patches back to upstream (which fails the dissident
> > test).
> 
> But, we need the freedom and ability to modify the software
> collectively, not just individually.  That *does* mean we should be
> able to share our changes with other downstreams of the same upstream,
> and with the upstream itself.
> 
> Furthermore, as a matter of being good free software citizens, we
> ought to try to send our patches to upstream.

I agree, we should use upstream's form.  But there is a distinct
difference between free software and the free software community.  The
primary purpose of free software is to provide freedoms to the
individual recipient of the software.  When there are also requirements
to "do it my way" (where "my" refers to upstream), the software is no
longer free.

One fundamental purpose of the free software community is to ensure that
free software thrives.  To this end, the recipient SHOULD (as in the RFC
meaning of SHOULD) make changes available to upstream and do so in a way
that upstream likes.  But changing that SHOULD to a MUST changes the
software from free to non-free.  Now you have (perhaps severely)
restricted the recipient's freedom to make changes.

Perhaps the term "communal software" better describes software that
requires modifications to be in a form acceptable to upstream.  You can
use this software, but if you want to modify it, you must become part of
the community and give patches in a form that the community likes.

By your definition, a complete fork of a piece of software would still
be required to use upstream's preferred form.  Even though the new fork
has a new upstream, changing the preferred form would be a violation of
the license terms, so the fork would not be allowed if the new upstream
preferred a different form.

> > My interpretation of "preferred form" is _any_ (explicitly not "the")
> > form which a significant percentage of persons who have experience
> > modifying that kind of software would agree that the given form is as
> > easy to modify as any other form, modulo some level of personal
> > preference.  Using upstream's preferred form is not required in order to
> > satisfy the license's preferred form.
> 
> I am, in general, unconvinced by these arguments.  In practice if
> upstream choose to modify things in form X, and do not accept
> modifications presented as changes to form Y, then I am unconvinced by
> arguments that form Y is "an also preferred form" for modification, or
> some such.
> 
> > Free software encourages, but does not require, giving back to the free
> > software community.  Free software _does_ require giving the recipient
> > equal footing to modify the software.
> 
> Your analysis takes no account of the fundamentally collaborative and
> collective nature of free software development.

Again, it is a difference between the recipient exercising his/her
freedoms based on the software being free, and being a good citizen
within the free software community.  Saying that you must be a good
citizen to exercise the grants of the free software license goes against
the principle of free software.

...Marvin

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Marvin Renich]

* german...@ya.ru  [160710 23:08]:
> Now I want to know if Debian Stable can in some extreme cases, like in
> this case with btrfs, replace not_very_good kernel module that is
> shipped with its current kernel with a kernel module from other (older
> or newer) version of Linux kernel and if yes, is it the case with
> btrfs?

I think you have a basic misunderstanding of what Debian means by
"Stable Release".  Debian's stable release is not a collection of stable
software; rather, it is a stable collection of software, some of which
might, individually, not be so stable.

This was pointed out to you at least once earlier in this thread, but
you continue to ask questions as if you either did not read or did not
understand that explanation.

The purpose of the stable release is to allow system administrators to
set up a system and know that as long as Debian supports that release,
only security updates and _major_ bug fixes will be made to the release.
Changes in functionality and new features will not be made.

This allows the stable release to be used in mission critical situations
where a stable system is required by (and this is the important part)
configuring the system with known stable software.

...Marvin

Re: [Pkg-javascript-devel] Bug#817092: Bug#817092: this browserified

[Marvin Renich]

* Jonas Smedegaard  [160711 07:08]:
> Quoting Pirate Praveen (2016-07-11 10:30:59)
> > On Sun, 10 Jul 2016 19:41:17 +0200 Jonas Smedegaard  wrote:
> > > The requirement of source format of redistributed code is not about 
> > > it being possible/easy to edit by those receiving it¹, but about it 
> > > being in the format preferred by _upstream_ to edit - e.g. for 
> > > passing patches upstream.

I have to disagree with this. The requirement for "preferred form of
modification" was explicitly to allow the recipient of the software the
freedom and ability to modify the software, not to force a particular
workflow (e.g. upstream's workflow) on the recipient, or require the
recipient to send patches back to upstream (which fails the dissident
test).

My interpretation of "preferred form" is _any_ (explicitly not "the")
form which a significant percentage of persons who have experience
modifying that kind of software would agree that the given form is as
easy to modify as any other form, modulo some level of personal
preference.  Using upstream's preferred form is not required in order to
satisfy the license's preferred form.

Without this flexibility, any use of Allman style indenting and braces
completely fails the "preferred form" test.  :-P

Free software encourages, but does not require, giving back to the free
software community.  Free software _does_ require giving the recipient
equal footing to modify the software.

...Marvin

Re: Fingerprint-GUI?

[Marvin Renich]

* Andrew Shadura  [160507 17:27]:
> Fingerprint readers are insecure, and that's something that can't be
> fixed. I'd prefer to see fewer fingerprint-related software packages
> in Debian rather than more.

I cringe when I see blanket statements like this from security
advocates.  Instead of saying "get rid of fingerprint readers", your
efforts would be more beneficial if they were directed towards education
of both the downsides of a particular technology and how to determine if
the security problems associated with it outweigh the benefits.

Your statement is analogous to saying that deadbolts are not going to
stop an experienced burglar who has cased your house, so all hardware
stores should stop selling deadbolts and only sell bank-vault-style door
locks.

I know of at least one fast food chain that uses fingerprint readers to
allow their employees to clock in and out.  Can an employee take
advantage of the insecurity of fingerprint readers to get a coworker to
clock him in early?  Probably.  If he does it regularly, will he get
caught?  Probably.  Do the risks to the fast food chain outweigh the
convenience of the technology?  I seriously doubt it.

I would like to see security advocates espousing use-case-based
security, rather than just saying "it isn't secure, so don't use it."

...Marvin

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

[Marvin Renich]

* Tollef Fog Heen <tfh...@err.no> [151208 04:33]:
> ]] Marvin Renich 
> > I set Acquire::Pdiffs::FileLimit "3"; and have been much happier.  Why
> > this (or something near this) wasn't the default from the start, I don't
> > know.  The current default is an extremely poor choice.  Perhaps someone
> > should file a bug (serverity critical :-P) to get the default changed.
> 
> I believe this has already been discussed,

Oh, I missed that discussion.  Was changing the default rejected, or is
it on the todo list, or was there no resolution?

> but what you really want is
> to do reverse diffs from today to dates in the past, not incremental
> diffs in the other direction.

That may be a better solution, but if mirror operators are not willing
to put up with the churn, then changing the default FileLimit seems like
the right (and obvious) compromise.  I don't see any downside to
changing the default, and it will give significant benefit.  If the idea
was rejected, I would really like to know why.

I've changed my config, so it is not really bothering me, personally.
But I would like the default to give the majority of Debian users the
best experience; the current setup does not.

...Marvin

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

[Marvin Renich]

* Vincent Danjean  [151208 03:17]:
> Le 06/12/2015 13:01, David Kalnischkies a écrit :
> > You can't update individual indexes at the moment. The question is why
> > you would want to as from my point of view that was a pretty annoying
> > technical detail that I had to run two (or three [debtags] or more)
> > commands to get all the metadata.
> 
>   I use "apt-file search" very sporadically. And even when I use it,
> most of the time, it is to find a package containing a header file,
> so I do not need its database to be up-to-date. So I update it only
> when the result from the first run is not good.
> 
>   Now, each apt{-get} update will update all Contents-Files for
> *all architectures* and *all suites*. I do not want that. It takes
> too long for data I do not need. It is especially annoying when I'm
> traveling, that I've only a limited (speed and/or size) data link
> and that I must upgrade/install a package.

I agree completely.  I only use apt-file once in a while, and I don't
mind running a separate command to update to Contents files, and I don't
think I have ever used apt-file when I was interested in anything other
than amd64/testing, though I have other archs/suites in my sources.list.

On the other hand, I run apt-get at least once a day.  I do not want to
have to wait for the Contents files every time I update my Packages
files.

If this is configurable, that's great, but I think the default (as I
interpret this thread) is a regression.  The default should be to not
download Contents, but describe (or point to a description elsewhere) in
the apt-file man page how to change the configuration so that Contents
are downloaded automatically on every apt-get update.

...Marvin

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

[Marvin Renich]

* David Kalnischkies <da...@kalnischkies.de> [151208 07:36]:
> On Tue, Dec 08, 2015 at 10:32:52AM +0100, Tollef Fog Heen wrote:
> > ]] Marvin Renich 
> > > * Tollef Fog Heen <tfh...@err.no> [151207 00:17]:
> > > > ]] David Kalnischkies 
> > > > > [And before someone complains about PDiff being slow in apt based on
> > > > > some years old experience: The PDiff handling was changed nearly two
> > > > > years ago… – and apt-file was using PDiffs before already, so no real
> > > > > change there]
> > > > 
> > > > Does this mean apt now will only download a single file, regardless of
> > > > whether it's grabbing the updates a pdiff or full packages file?  In the
> > > > past, the problem for me has been that you end up being latency-bound,
> > > > rather than bandwidth-bound.
> > > 
> > > I set Acquire::Pdiffs::FileLimit "3"; and have been much happier.  Why
> > > this (or something near this) wasn't the default from the start, I don't
> > > know.  The current default is an extremely poor choice.  Perhaps someone
> > > should file a bug (serverity critical :-P) to get the default changed.
> 
> I somehow can't believe that downloading a few kilobytes split into
> multiple files is slower than downloading the entire file and I said

Okay, if pdiff handling has improved considerably since it was first
released, this could be true.  I have had FileLimit in my config since
soon after I first saw the feature.  All I know is that when I first saw
this, my updates started taking considerably longer, and the time was
spent mostly "connecting to...", not downloading.  I saw somebody
suggest FileLimit, tried it, and my update time reverted back to where
it had been, perhaps even less.  (My laptop is the only machine I update
daily; I have several other machines that are updated much less
frequently, and my experience with pdiffs was across the board.)

I never meant to say that pdiffs is not a good feature.  On the
contrary, I think it is great.  My experience, though, was that too many
pdiffs took longer elapsed time than downloading the original file.

And thanks go to you and the rest of the apt team for all the work you
do to make apt better, by far, than any other distribution's packaging
system.

...Marvin

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

[Marvin Renich]

* Tollef Fog Heen  [151207 00:17]:
> ]] David Kalnischkies 
> 
> > [And before someone complains about PDiff being slow in apt based on
> > some years old experience: The PDiff handling was changed nearly two
> > years ago… – and apt-file was using PDiffs before already, so no real
> > change there]
> 
> Does this mean apt now will only download a single file, regardless of
> whether it's grabbing the updates a pdiff or full packages file?  In the
> past, the problem for me has been that you end up being latency-bound,
> rather than bandwidth-bound.

I set Acquire::Pdiffs::FileLimit "3"; and have been much happier.  Why
this (or something near this) wasn't the default from the start, I don't
know.  The current default is an extremely poor choice.  Perhaps someone
should file a bug (serverity critical :-P) to get the default changed.

...Marvin

Re: service failures should not fail dpkg installation

[Marvin Renich]

* Paul Gevers <elb...@debian.org> [150924 14:12]:
> Hi
> 
> On 24-09-15 18:21, Henrique de Moraes Holschuh wrote:
> > On Thu, 24 Sep 2015, Marvin Renich wrote:
> > What we really want is a "do not fail upgrade, BUT report that some services
> > *that were previously running* failed to restart after the upgrade run".
> > 
> > ESPECIALLY if you are going to take "unattended upgrades" seriously.
> > 
> > Still, that would need some proper design work, and a reasonable amount of
> > code to be written and tested.  Some of it will hook into the package
> > system, some of it needs to interface to the services subsystem (systemd,
> > sysvinit, others).

I agree, but I don't think we should wait for this feature to appear
before fixing packages to _not_ fail upgrades when the service fails to
start.  The current situation does more harm than good.

> I would like to add there is more than just services. As the current
> maintainer of dbconfig-common, it is more than clear to me that updates
> of packages that require updates of (and even installs into) databases
> (tables and/or their contents) also fall into this category. If for
> whatever reason we can't connect to the database (which may even be on a
> different system), there is currently not much that we can do except
> register failure. I am currently of the opinion that if that happens,
> the package upgrade DID fail, as the package probably won't be working
> until the upgrade commands are applied with a working connection. (Just
> before people start shouting, the way dbconfig-common handles this is by
> asking the administrator if the problem should be fixed by retrying,
> ignoring the problem or considering the issue a failure. In
> noninteractive mode, the problem is ignored for installs and removals,
> but not for upgrades.)

I agree completely.  The decision on whether or not to fail the dpkg
installation should depend on what action needs to be taken to correct
the situation (and this is true whether we are talking about a service
failing to start or a database upgrade failure or something else).

However, most existing cases of service restart failures require
something other than re-running the dpkg installation to fix them, and
the default, without careful thought by the maintainer about the
possible failure modes, should be to allow the dpkg run to succeed.

Should I open a wishlist bug against the developers reference pointing
to this discussion?

...Marvin

service failures should not fail dpkg installation [was: Re: promoting virtualbox-dkms to virtualbox pre-depends]

[Marvin Renich]

* Jeroen Dekkers <jer...@dekkers.ch> [150924 07:23]:
> At Wed, 23 Sep 2015 13:53:11 -0400,
> Marvin Renich wrote:
> > I think it should be documented in the developers reference that if you
> > attempt to start or restart a service in postinst, you should guard it
> > so that a failure in the service does not propagate to a failure of the
> > postinst.
> 
> But then when something goes wrong when upgrading and the service
> doesn't (re)start apt/dpkg will report success but the service isn't
> running anymore. That also sounds wrong to me. Letting postinst fail
> might not be the best way to signal this, but to change that we need
> something else to let the user know that something went wrong. Just
> printing an error message isn't enough, because the user might not see
> that (for example when multiple packages are installed/upgraded and a
> later package asks some questions using dialog or when using
> unattended-upgrades).

How does failing the upgrade solve anything?  The upgrade should only
fail if the failure of the service to start was because something in the
upgrade itself was broken; this is rarely the case.

There are two prominent reasons why a service fails to start after an
upgrade:  the relationship between the application and its configuration
has changed (e.g. different, incompatible defaults or incompatible file
format) or some external influence that has nothing to do with the
upgrade (e.g.  unavailable resource).

The first case requires the admin to sort out the changes and fix the
configuration.  Being required to re-run the dpkg installation just to
flip the 'half-configured' state to 'installed' when the result would
have been the same if dpkg had not failed the first time is wrong.

In the second case, how is it a dpkg installation failure if the
hypervisor is not running so xen won't start?  Everything is installed
perfectly.  Or if a daemon fails to start because the ldap server on a
different host is down?  Failing the installation is _really_, _really_
_wrong_!

What makes this even worse is that when installing or upgrading a large
number of packages, this kind of incorrect failure sometimes affects
many completely unrelated packages.  For an unattended upgrade, this is
so much worse than having one service that (for a correct reason)
refused to restart after the upgrade.

What you are looking for is a more prominent notification that a service
did not restart.  But the current situation is like the "check engine"
light flashing when you are low on fuel; yes, it gets your attention,
but it is telling you the wrong thing.

...Marvin

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Marvin Renich]

* Ritesh Raj Sarraf  [150923 07:47]:
> On Wed, 2015-09-23 at 13:23 +0200, Ansgar Burchardt wrote:
> > Gianfranco Costamagna  writes:
> > > the problem actually is that virtualbox-dkms should be configured
> > > *before* configuring virtualbox
> > 
> > Why should this need Pre-Depends instead of Depends assuming
> > virtualbox
> > depends on the -dkms package?
> 
> Hello Ansgar,
> 
> Please see attached terminal log from APT. I have copied the relevant
> sections. It shows the purpose of vbox-dkms and why exactly virtualbox
> package fails.
> 
> Also, the same has been discussed in following bug reports.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798979
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798527

The logs (that I snipped) were from an installation of the versions
where virtualbox-dkms incorrectly had a Depends on virtualbox.  This
does nothing to justify using Pre-Depends.  Using Pre-Depends is wrong.

...Marvin

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Marvin Renich]

* Ritesh Raj Sarraf  [150923 04:06]:
> Adding Moritz from the DSA.
> 
> On Tue, 2015-09-22 at 19:59 +0200, Julien Cristau wrote:
> > On Tue, Sep 22, 2015 at 15:00:35 +, Gianfranco Costamagna wrote:
> > 
> > > As shown in policy 7.2
> > > 
> > > "You should not specify a Pre-Depends entry for a package before
> > this has been discussed on the debian-devel mailing
> > > list and a consensus about doing that has been reached. See
> > Dependencies, Section 3.5."
> > > 
> > > the problem actually is that virtualbox-dkms should be configured
> > *before* configuring virtualbox, otherwise
> > > without a built kernel module, restarting VMs
> > > will fail and lead to an half-configured package.
> > > 
> > > Please see bugs #798527 and #798979 as examples.
> > > 
> > > (this is a subpackage depending on another subpackage that belongs
> > to the same src, I don't get why I should discuss such internal
> > > changes, but well, policy is policy)
> > > 
> > A pre-depends is very much the wrong hammer here, userspace can't
> > usefully rely on a kernel package or module through package
> > dependencies.
> 
> Can you please elaborate here ?
> 
> 
> Problem is: virtualbox is picky about the version of the kernel module
> in use. Which is provided by virtualbox-dkms package.
> 
> We earlier did have the Depends logic, which broke. I don't think the
> breakage was racy. It was something just not noticed commonly.
> 
> By putting the tighter dependency, we are instructing virtualbox wait
> until virtualbox-dkms has completed its installation, which effectively
> is: roll out the new kernel dkms package, built the new kernel modules,
> and load them. That is exactly what virtualbox package will need before
> it can upgrade itself.
> 
> 
> Looking at the Pre-Depends details on the policy document, it looks in
> line with what we want:
> 
[policy quote snipped]

No.  Pre-Depends says to unpack and configure another package before
even unpacking this package.  Depends says to make sure the other
package is both unpacked and configured before _configuring_ this
package, but it is okay to unpack this package prior to that.

Pre-Depends is truly the wrong hammer here, regardless of whether we are
talking about kernel modules or normal user software.

The problem originally was that you had the Depends the wrong way
around.  You had the vbox-dkms package with a Depends on the vbox
package (which was completely wrong; there was no need for that at all),
and the vbox package with a Recommends on vbox-dkms.  This forced vbox
to be both unpacked and configured before vbox-dkms was configured,
which caused your problem.

Another poster's comment was that just raising the vbox Recommends
vbox-dkms to a Depends would create a circular dependency, which would
not guarantee that vbox-dkms was configured first.  However, both
raising vbox to Depend (_not_ Pre-Depend) on vbox-dkms _and_ lowering
the vbox-dkms Depends vbox to a Recommends breaks the dependency cycle
and forces vbox-dkms to be configured first, which is what you are
trying to accomplish.

On the other hand, other posters here have said that package-level
dependencies are the wrong hammer for enforcing kernel module
dependencies, and they are right.

What might work, as a better kludge than using Depends to mean "in most
cases when vbox is installed, vbox-dkms or vbox-source should also be
installed [which is the definition of Recommends], and if either is
installed, we want the module to be built and loaded before starting the
vbox service [which is what you are trying to accomplish using
Pre-Depends]", is to use Recommends in both places, which expresses the
correct package relationship, and then use dpkg triggers to start the
vbox service after all packages in the dpkg installation run have been
configured.

This works whether the user has a custom kernel or a stock Debian
kernel, as long as they have the module installed one way or another.
And if they don't, they will get the appropriate error message from the
vbox service.

I have not used dpkg triggers myself, so I may have this wrong, but this
is what I would try.  There may be a better solution, but I can't think
of one at the moment.

Pre-Depends is highly misunderstood, and this thread is a good example
of why policy dictates that using it should be discussed on this list
first.

...Marvin

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Marvin Renich]

* Marvin Renich <m...@renich.org> [150923 07:52]:
> What might work, ..., and then use dpkg triggers to start the
> vbox service after all packages in the dpkg installation run have been
> configured.

If I understand correctly how dpkg triggers work, this could cause a
restart of vbox before the module is installed, but then it should also
cause a second restart after it is installed.  (I.e. you could get a
spurious failing restart in the middle, but when the dust settles, all
should be well.)

This is caused by apt and aptitude breaking up large installations into
multiple calls to dpkg.  Each call to dpkg will cause the triggers to be
run, so if apt(itude) happens to separate the vbox and vbox-dkms
installations into separate runs of dpkg, vbox might be restarted the
first time with the wrong module, but it will be corrected in a
subsequent run.  This assumes correctly using Recommends instead of
Depends.  As I (and others) said earlier, not only is Pre-Depends wrong,
but Depends is also wrong in this situation.

...Marvin

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Marvin Renich]

[please do not CC me; I am subscribed]

* Ritesh Raj Sarraf  [150923 11:50]:
> Okay!!  But, btw, can someone enlighten the use case for Pre-Depends ??

If you need to use something from another package in your preinst
script, you will need a Pre-Depends.  For example, cron Pre-Depends:
dpkg because the preinst script for cron uses dpkg-maintscript-helper
which is in dpkg.

...Marvin

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Marvin Renich]

* Ritesh Raj Sarraf  [150923 12:54]:
> > Each call to dpkg will cause the triggers to be run, so if
> > apt(itude) happens to separate the vbox and vbox-dkms installations
> > into separate runs of dpkg, vbox might be restarted the first time
> > with the wrong module, but it will be corrected in a subsequent run.
> 
> Hmmm.. I think I have seen this kind of error some time ago.
> 
> So how is such error supposed to be treated ? Ignore it ? I guess the
> final result of apt is still a success, in such cases.

First, you should start your service in the trigger, not in your
postinst.  From the dpkg man page (I am really stretching with this
inference, so someone else can clarify) it looks like a failure in the
trigger will leave the package in the triggers-pending state.  However,
you should make sure the trigger does not fail even if the vbox service
does not start correctly.



>From the first time I had dpkg mark a package as half-configured when
everything was correct except that the service would not start for some
reason that had nothing to do with package installation (exactly the
situation here for virtualbox), I have felt that dpkg had no business
failing just because the service would not start.  I think that is a
wrong design decision.

In fact, one specific case that often hurts me is when I have xen
installed on a machine where I only run the hypervisor occasionally.
Upgrading the xen packages causes (or has caused in the past) the
upgrade to fail.  This is ridiculous!

I think it should be documented in the developers reference that if you
attempt to start or restart a service in postinst, you should guard it
so that a failure in the service does not propagate to a failure of the
postinst.



...Marvin

Re: Security concerns with minified javascript code

[Marvin Renich]

* Bas Wijnen <wij...@debian.org> [150902 17:36]:
> > On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich <m...@renich.org> wrote:
> > > No, "A preferred form" is what upstream uses.  The DFSG does not use
> > > the term "THE preferred form", and I believe that was wise.
> 
> The DFSG doesn't define source at all.  There seems to be consensus (you're 
> the
> only one who doesn't seem to agree) that the definition from the GPL is a good
> one, and that does say "the".

Quoting from [1]:
  The process involves human judgement. The DFSG is an attempt to
  articulate our criteria. But the DFSG is not a contract.

People keep trying to use "the preferred form for modification" as a
rule.  This is wrong.  The rest of the paragraph quoted above should
also be read.

I do strongly believe that "preferred form for modification" is a good
test to apply, but it is not an absolute.  I also believe that sometimes
there is more than one form of source that can satisfy the DFSG.  A
simple example is the .xcf/.png/.ico example I gave in a previous
message.  This is why I disagree with using "THE" (implying only one)
instead of "A" (implying one of many).

> > > There can be multiple "preferred forms" for some software, and all are, in
> > > my opinion, acceptable by the DFSG.  The real question is whether it is
> > > reasonable to expect someone who wishes to modify the software to consider
> > > the form "source".
> 
> I disagree partly.  It is possible to copy a generated file and use that as
> source.  IMO that isn't the case until there have actually been made
> modifications to that file, though.  If an upstream (which doesn't need to be
> the original upstream) actually uses a file to make modifications, an argument
> can be made that this format is source.
> 
> At the same time, we should try to convince upstreams that do such a thing to
> stop it; it causes code duplication and a (security) support nightmare.

I'm not sure how that is relevant to what I said.

> "Someone might think they can make modifications to this file" is much too
> broad; for some modifications a hex editor is good enough.  And in some cases
> that is totally reasonable, such as an executable for which you don't have
> source.  That doesn't make binary exectutables source.

That is not at all what I said.  To paraphrase, using a circular
definition, if I can _reasonably_ _expect_ most other people to agree
that it is source, then that is a very good indication that it is
source.

...Marvin

[1] https://people.debian.org/~bap/dfsg-faq.html#testing

Re: Security concerns with minified javascript code

[Marvin Renich]

* Neil Williams <codeh...@debian.org> [150902 14:15]:
> On Wed, 2 Sep 2015 13:14:31 -0400 Marvin Renich <m...@renich.org> wrote:
> > It is presumed that upstream already has what it considers "source";
> > in the case of this thread, that is minified JS.
> 
> Actually, not. Source, for upstream of JQuery at least, is a set of
> directives to include files into a non-minified jquery.js which is then
> minified as part of the build in Debian.

I stand corrected.

> There are three players:
[large snip]
> It is a complete mess - with the embedding upstreams lost in the middle
> with no idea of what they can do to avoid getting in the way.

I completely agree.

...Marvin

Re: Security concerns with minified javascript code

[Marvin Renich]

* Neil Williams <codeh...@debian.org> [150902 14:33]:
> Minified isn't source for modification... [large snip]

I don't believe I have disagreed with anything you said in the snipped
text.  I certainly did not mean to.  I said that minified JS can only go
in main if both the source and the tools to build it are also in main.
I also said that this is a hard problem to tackle, but Debian should
tackle it (which is what this thread appears to be doing) instead of
ignoring it.

> On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich <m...@renich.org> wrote:
> > This whole thread is about...
> 
> It's not about contrib or main, that is roughly equivalent to thinking
> that every DFSG problem looks like a nail because all you have available
> is a large hammer instead of solving the problem inside main.

First, I will retract the phrase "this whole thread"; I should have said
the points in the thread to which I was responding.

Second, I was not proposing any solution to the problem or agreeing with
anyone's solution.  All of my posts were about exposing incorrect
interpretations of the term "source" in the DFSG.  I think, though I'm
not quite sure, that I replied to posters on both sides of the debate (a
large part of this thread does appear to debate what is required for
minified JS to go in main).

Perhaps my posts were misinterpreted as endorsing or opposing a specific
solution?

...Marvin

Re: Security concerns with minified javascript code

[Marvin Renich]

* Ben Hutchings  [150902 10:12]:
> My preferred form is a git repository of code written in C, Python, or
> some other language I know.  That doesn't mean that a tarball of
> Haskell code is non-free!

I can't tell whether you are agreeing or disagreeing with me!

> The preferred form for modification is generally whatever form an
> upstream developer will load into a text editor or other interactive
> editing tool.

No, "A preferred form" is what upstream uses.  The DFSG does not use the
term "THE preferred form", and I believe that was wise.  There can be
multiple "preferred forms" for some software, and all are, in my
opinion, acceptable by the DFSG.  The real question is whether it is
reasonable to expect someone who wishes to modify the software to
consider the form "source".

Again, this is specifically about the DFSG, not the whole Debian Social
Contract.

This whole thread is about how Debian can conform to some points of the
DSC (e.g. points 4 and 2) by providing packages containing minified JS,
and still conform to the DFSG, and whether that means some packages that
are currently in main need to be moved to contrib or non-free.  The
point of contention is not "should we package this software for the
benefit of our users" but whether the packages are allowed in main,
which is strictly based on whether or not they conform to the DFSG.

...Marvin

Re: Security concerns with minified javascript code

[Marvin Renich]

* Neil Williams  [150902 10:22]:
> Upstream is another recipient of code distributed under copyleft.
> Having changes in a format which upstream can use is absolutely a
> sensible and sane criterion for what is regarded as the form of the
> code for modification. To do otherwise is to make the maintenance
> burden untenable.
> 
> Every recipient needs to get the source code and the maintainer changes
> in a format which is suitable for modification and that includes
> the work of modification required to incorporate those changes into the
> next upstream release. To rule out upstream requirements is nonsense.

The whole point of this discussion is what does Debian require of
upstream for upstream to get its software distributed in Debian main.
It is presumed that upstream already has what it considers "source"; in
the case of this thread, that is minified JS.

My point is that if what upstream considers to be "source" is not
acceptable to Debian, and the Debian packager has to grab real source
from other places and use a build process that is different from what
upstream uses in order to make the Debian package satisfy the DFSG, then
upstream's wishes are not relevant to whether the Debian package
conforms to the DFSG.

Furthermore, if the Debian packager does not like upstream's arrangement
of source, even if it would satisfy the DFSG, and wishes to rearrange
it, whether or not the packager's arrangement satisfies the DFSG's
meaning of source should be judged on its own merit, not on whether
upstream is willing to accept patches based on the Debian packager's
arrangement.

I am _not_ saying this this is necessarily a good decision.  The
distinction is between the DFSG, which is one part of the Debian Social
Contract, and the whole DSC.  DSC point 2 requires that the Debian
maintainer give back to upstream.  But that has nothing to do with what
satisfies the DSFG definition of source.

My argument is not that Debian should not use a form that upstream
likes, but that the definition of "source" for purposes of the DFSG is
independent of upstream's definition of source.  If both source forms A
and B satisfy the DFSG, and upstream uses form A, that does not make
form B fail to satisfy the DFSG, even for Debian packages of upstream's
software.

...Marvin

Re: Security concerns with minified javascript code

[Marvin Renich]

* Thorsten Glaser  [150902 07:50]:
> There is (I just had an epiphany) another possible criterium to apply
> for to determine what the preferred form of modification is:
   ^ for
  [Okay, so I'm being pedantic, but this is a common mistake.]

> Does upstream accept patches for that form?

I thoroughly and whole-heartedly disagree with this criterion.  As I
stated in an earlier message, the purpose of the source requirement in
the DFSG (and GPL, etc.) is not to protect the rights of the persons
distributing software, but those receiving the software.  There is no
requirement that changes to the software be returned to upstream; such a
requirement would violate the dissident and desert island tests¹.

The source requirement is so that the recipient can make changes if
desired, and if the changes are redistributed (not passed back to
upstream), the second-level recipient may also make changes.

Any test of preferred form for modification must be in terms of how the
recipient is able to use it, not how the distributor would like it.

...Marvin

[1] https://people.debian.org/~bap/dfsg-faq.html#testing

Re: Security concerns with minified javascript code

[Marvin Renich]

* Raphael Hertzog  [150901 12:57]:
> Because we have alternative "compilers" (aka minifier) available to
> recreate another minified file thas should work just as well.

No.  Debian does not allow you to ship a compiled C program that was
compiled elsewhere; the maintainer or a buildd is responsible for taking
the source and creating an executable.  The same applies to minified JS.
I don't see how anyone can argue that minified JS is different.

(And besides, "different but works just as well" is not even close to
the same as "could be built from source, but just wasn't".)

Sometimes doing the right thing is hard.  The GFDL issue is an example;
it took a large effort and a lot of time, but we finally did it.  We did
not remove all GFDL source in one shot.  We decided it really was a
problem, started filing bugs, and started fixing them.  I believe there
was a release in the middle of the purge that ignored (for RC purposes)
those bugs, but we did eventually get all GFDL-licenced material moved
to non-free.

We should do the same for minified JS that is not built using tools in
main.

...Marvin

Re: Security concerns with minified javascript code

[Marvin Renich]

> On Mon, Aug 31, 2015 at 11:21:55AM -0400, Marvin Renich wrote:
> > * Bas Wijnen <wij...@debian.org> [150830 07:53]:
> > > On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> > > > Is that the preferred form of modification? It depends, but from the
> > > > jQuery author point of view, it isn't:
> > > 
> > > Then it isn't.
> > 
> > I take exception to this.
> 
> I agree with your point.  What I meant to say is that what upstream actually
> uses for modifying the work is what we should use as source.  That may change
> if upstream changes, and it may not be a clear definition anyway if upstream
> consists of multiple people and they have different ideas about it.  But most
> of the time this is very clear; if you send a patch and they say "that's not
> the file I use for editing", then it's not the source.

Okay, in general what upstream uses (if it satisfies Debian's definition
of source) is what we should try to use if we don't have a reason to do
otherwise, but not doing so does not violate the DFSG.  That is not the
purpose of the DFSG requiring source.  The purpose is so that
downstreams can fork, using their own repositories and distribution
mechanisms, and perhaps different mandatory coding styles for acceptance
into their repos.  And then a downstream of a first-level downstream can
do the same.

Perhaps one downstream likes to refactor to decrease the total number of
files, and another likes to decrease the average number of lines per
file.  Both are still valid DFSG-compliant source.

> > Also note that the phrase "preferred form of the work for making
> > modifications to it" comes from the GPL, not from the DFSG.
> 
> True, but we don't have a definition ourselves, and there seems to be 
> consensus
> that this is a good one.

Agreed.

...Marvin

Re: Security concerns with minified javascript code

[Marvin Renich]

First, let me make it clear that I am firmly in the camp that believes
minified JS cannot be distributed in main unless the tools to recreate
it are also in main.  It bothers me that there appears to be a
not-insignificant number of people with upload rights who do not believe
this.

This message is not about that, though.

* Bas Wijnen  [150830 07:53]:
> On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote:
> > Is that the preferred form of modification? It depends, but from the
> > jQuery author point of view, it isn't:
> 
> Then it isn't.

I take exception to this.  A number of discussions about "preferred form
for modification" have taken place over the years, and one of the
opinions often set forth is that there is only one "preferred form" for
any given source.  The fact is that different developers have different
preferences.

The fact that the original developer of some software used gimp to
create a simple icon does not mean that the gimp .xcf file must be
considered the preferred form for modification.  Both .png and .ico can
be modified just as easily; in fact there are many more tools in Debian
that can edit those formats than .xcf files.

The basic purpose of the phrase "preferred form for modification" is to
ensure that the right to modify the software is not hindered by only
having an obfuscated version of the source.  I would like to say "any
form of the source that can easily be modified should be allowed," but I
am not sure that I can go quite that far without any qualifications.

Also note that the phrase "preferred form of the work for making
modifications to it" comes from the GPL, not from the DFSG.

> > However, this is a readable source code that will accomodate any
> > modification that a end user will deem necessary.

I intentionally did not look at the file referred to above, and have no
idea whether I would consider it to be a "preferred form" or not.  I
merely wanted to debunk the "original author's preferred form is the
only form that can be considered preferred" statement.

...Marvin

Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

[Marvin Renich]

* Joachim Breitner nome...@debian.org [150823 07:24]:
 With pow-priority, you mean one that does not get shown by default? But
 is that much better than allowing the interested admin to change the
 configuration afterwards?

Actually, I was thinking it should be similar to postfix, which looks
like it is using medium priority for most questions (sorry, that was my
mistake).

 Note that my package does _not_ touch or put files in /srv. It merely
 uses files that are put in a certain directory that, that the admin has
 to create first. Does that mitigate your concerns?

Somewhat.  Still, it mandates that a specific directory in /srv be used.

Current practice in Debian, based on a very small sample, is to use a
subdirectory of /var, such as /var/www or /var/lib/pkgname.  You would
certainly be following precedent if you did something like this.

However, after reading bug #775318 (CC'ed, as the rest of this message
pertains to this specific package as well as the debian-policy bug), I
am forming some new opinions.

First, it now appears to me that the FHS authors:

1.  intended for /srv to be used for things like this.

2.  intended for the structure of /srv to be primarily under control of
the local admin.

3.  recognized that this directory was relatively new and best practices
had not been established.  They intentionally left the details
unspecified to allow distributions to arrive at a consensus.

In order for both distributions and local admins to safely share /srv,
there must be some rules about how the namespace is divided.  For /usr
and /var, distributions were alloted all except one subdirectory of
each:  /usr/local and /var/local.  This gives distributions primary
control over these two top-level directories.

To give local admins primary control of /srv, we should do the converse,
and reserve one top-level subdirectory for distributions (perhaps
/srv/pkg; other suggestions welcome), and leave the remainder of the
/srv namespace available for the local admin.  So you might use
/srv/pkg/local-apt-repository.

There currently does not appear to be any precedent in Debian for a
package to use /srv as a default, so it would be nice for the first
package to do so to get it right.  Once packages start usurping
top-level subdirectories of /srv, it will be difficult to ebb the tide.

I do think that for packages where it makes sense to use a subdirectory
of /srv, it also makes sense to ask the admin what directory to use,
giving a sensible suggestion as a default.

...Marvin

Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

[Marvin Renich]

* Joachim Breitner nome...@debian.org [150822 09:04]:
 Hi Jakub,
 
 Am Samstag, den 22.08.2015, 14:54 +0200 schrieb Jakub Wilk:
  * Joachim Breitner nome...@debian.org, 2015-08-22, 13:58:
   With this package installed, every Debian package (i.e. a *.deb 
   file) 
   dropped into /srv/local-apt-repository
  
  Sounds like an FHS violation: “no program should rely on a specific 
  subdirectory structure of /srv existing or data necessarily being 
  stored in /srv.”
 
 this was just discussed on IRC. Here is my rationale:
 
 Packages to be added to the repository fit the description of /srv
 quite perfectly. I quote.
 
 /srv : Data for services provided by this system
 Purpose
 
 /srv contains site-specific data which is served by this system.
 
 This main purpose of specifying this is so that users may find the
 location of the data files for particular service, and so that
 services which require a single tree for readonly data, writable
 data and scripts (such as cgi scripts) can be reasonably placed.
 Data that is only of interest to a specific user should go in that
 users' home directory. 
 [..]
 
 
 So it is not wrong to use this directory. Also, all alternatives are
 wrong in some way as well.

I was under the (perhaps mistaken) impression that part of the purpose
of /srv was to allow complete admin discretion with the directory
structure, and that distributions were not to mandate any specific
directory names.

A low-priority debconf question asking the admin what directory to use,
suggesting /srv/local-apt-repository, would satisfy that.  If the
question is not asked (or preseeded) the package would remain
unconfigured.  This would not be the only package to require explicit
admin configuration to be operational, and the required configuration
would be very minimal.

Both apache2 and lighttpd use /var/www/html as the default directory to
serve, and do not touch /srv automatically.  I don't know of any Debian
package that puts files in /srv.

While I agree that having a service fully functioning immediately after
installation is usually a desirable goal, I believe that it is more
important to not interfere with an admin's authority.  The /var/local
directory was needed so admins had a directory that was guaranteed to
not be stepped on by the package manager.  If we start letting packages
put things in /srv, then we may end up needing /srv/local for the same
reason, when /srv should already serve that purpose.

...Marvin

Re: Metapackage dependencies: Depends or Recommends?

[Marvin Renich]

* Neil Williams codeh...@debian.org [150729 03:30]:
 I'd still use Depends in the metapackage. e.g. foo-server has lots of
 strict dependencies without which is simply won't install or start.
 foo-client has less dependencies and a few Recommends because the
 client can work for a range of usecases and not everyone needs every
 use case.
 
 For those people who *do* want the assurance that every possible use
 case can work, then a foo metapackage would Depend on foo-server and
 foo-client and *all* of the Recommends of foo-client, possibly
 including even a few of the Suggests of foo-client.

For those people, don't change the default Apt::Install-Recommends and
you get the desired behavior with metapackages that use Recommends.  But
those of us who want most, but not all, of a metapackage can still get
what we want, too (with either setting of Install-Recommends).

If a metapackage uses Depends, the only way to install all but one
subpackage from the metapackage is to manually install all the desired
subpackages; but then you do not get the auto-installed behavior, so you
cannot easily remove the (non-)metapackage.  You also do not get the
benefits of updates to the contents of the metapackage.

No downside to Recommends; no upside to Depends.

Think of Recommends as defaults to Depends, but can easily be
overridden by the user at install time.

Depends should be used when not installing the package causes functional
breakage rather than logical breakage or loss of functionality.

Recommends should be used when not installing the package makes sense if
the user is willing to put up with reduced functionality.

I think much of this debate is caused by users who set
Install-Recommends to false, but then want some of the benefits of
leaving it at the default of true.

I do set Install-Recommends to false, but I understand the trade-off I
am making.  I mostly use the aptitude curses interface, and I take a
little more time to go through the list of Recommended packages to
select the ones I want before pressing g a second time.  And yes, I do
mark those packages as automatically installed.

Using Recommends allows the user to choose which side of the trade-off
to be on.  Using Depends forces the install everything, no opportunity
to spend a few extra seconds to choose what you want on everybody.

...Marvin


-- 
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/20150731121623.gk21...@basil.wdw

Re: Metapackage dependencies: Depends or Recommends?

[Marvin Renich]

* Josh Triplett j...@joshtriplett.org [150729 17:18]:
 Ole Streicher wrote:
  Other packages will never depend on this metapackage; they will rather
  depend on the individual programs.
 
 Other packages *in Debian* will not.  I actually build a pile of
 personal metapackages to set up systems, and many of their dependencies
 are metapackages.  If metapackages start using Recommends, that would be
 quite inconvenient, as it would mean that I'd have to manually copy the
 list of dependencies into my metapackage (and update it if the set of
 needed packages changes) rather than just depending on the metapackage.

I don't understand this.  Why would having a Debian metapackage A which
_correctly_ uses Recommends make your personal metapackage B which
Depends on A fail to install the recommended packages from A?

Even if it did, how would that justify misusing the dependencies?

...Marvin


-- 
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/20150729213239.gj21...@basil.wdw

Re: Metapackage dependencies: Depends or Recommends?

[Marvin Renich]

* Andreas Tille andr...@an3as.eu [150729 04:14]:
 On Tue, Jul 28, 2015 at 10:51:02AM -0700, Russ Allbery wrote:
   I'm sure this is personal taste, and in the end it won't matter for most
   people (except folks who don't install Recommends, but they're going to
   break their system regardless),
  
  I've had Recommends disabled for something like five years.  My systems
  have yet to break.  :)
 
 And you did so because you are not a typical user of metapackages due to
 your deep insight into the packaging system and things you need. 

Exactly.  The point is that if metapackages use Depends, advanced users
cannot use the metapackages in advanced ways.  For the naive user, using
Recommends gets the desired effect, but still allows the advanced user
to pick and choose.  No downside to Recommends, no upside to Depends.

...Marvin


-- 
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/20150729133539.gh21...@basil.wdw

Re: Metapackage dependencies: Depends or Recommends?

[Marvin Renich]

* Simon McVittie s...@debian.org [150728 08:55]:
 On 28/07/15 13:08, Marvin Renich wrote:
  There is no downside to using Recommends and no upside to using Depends
  for metapackages.
 
 I don't think it's that simple; it comes down to a question of what the
 metapackage means, which is a design question for its maintainer.
 
 For metapackages that exist to make upgrades work (dummy packages),
 usually only Depends make sense: the package's entire purpose is to make
 sure old dependencies pull in what's needed.

Agreed.  Transitional packages are a separate issue.

 Tasks and task-like metapackages can be a mixture of both. It would make
 no sense for xfce4 to drop its Depends on xfwm4 down to a Recommends: if
 you don't have xfwm4, it is simply not true that you have the core
 packages of the Xfce4 desktop environment and the package database
 shouldn't claim that you do.

I still disagree.  If I want most of the core xfce4, but not quite all,
I should be able to install the metapackage and remove one or two items.
Both window manager and file manager are specifically things I might
wish to replace.  Your example is a very good demonstration of why
Recommends is appropriate.

 Perhaps the right question to be asking is: if foo has a RC bug, does
 that inherently make the task-bar metapackage unreleasable? If yes, then
 task-bar Depends on foo; if no, then task-bar Recommends (or even
 Suggests) foo.

No.  If foo has an RC bug, any package that would be functionally broken
should have a Depends.  The metapackage might be logically broken^W less
useful, but it is not functionally broken.

 Applying that logic to the xfce4 metapackage: if xfwm4 had a RC bug and
 got kicked out of testing, then the XFCE suite would not be not usable,
 so we should also consider xfce4 to be RC-buggy.  Good; it should have a
 Depends, which it does.

If xfwm4 had an RC bug, the XFCE suite may be logically broken, and the
maintainers may not wish to distribute the rest of the XFCE packages
without it, which might mean removing the metapackage xfce4.  But using
a Depends in the metapackage is not necessary to accomplish that.

If some of the other XFCE packages require xfwm4 and will break if you
use a different window manager, then they (the non-metapackages) should
have an appropriate Depends.

A metapackage should not be used as a bat to beat users into installing
ALL of something.  It should be a tool to help users install all of
something if they wish, but users should still have as much control as
is reasonable to pick and choose a partial subset if it works for them.

...Marvin


-- 
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/20150729140352.gi21...@basil.wdw

Re: Metapackage dependencies: Depends or Recommends?

[Marvin Renich]

* Ole Streicher oleb...@debian.org [150728 05:15]:
 Hi,
 
 I recently created two metapackages (astromatic and eso-pipelines) which
 were accepted by the ftp-masters yesterday. However, I got a commend
 that my choice of Recommends dependencies is discouraged:
 
 Paul Richards Tagliamonte ftpmas...@ftp-master.debian.org [1]:
  using Recomends and not Depends on the metapackage strikes me as very
  awkward. I think I get what you're trying to do (allow folks to remove
  one package they don't want, I guess), but I really don't think that's
  quite right.
 
 What is the rationale behind this? From the policy, I would think that
 Recommends is the perfect dependency here [2]:
 
 | Recommends
 | This declares a strong, but not absolute, dependency. The Recommends
 | field should list packages that would be found together with this one
 | in all but unusual installations.
 
 Why should one use the much stronger Depends here?

I strongly believe Recommends is correct.  First, this is clearly what
the policy states.  Second, it allows you to use the package manager the
way it was intended (which is the reason for the definition in policy).

If you use Recommends, you put the user in control of what is on his/her
system.  You can install the whole metapackage, or just the parts you
want, but still have the whole thing removed by removing the
metapackage.

If you use Depends, the user has two choices, install everything, or not
use the metapackage.

Take the metapackage games-finest.  If all of those packages were
Depends instead of Recommends, you could not remove a small handful of
the larger games (e.g. wesnoth, at 153M) without marking every single
game you wanted to keep as manual and then removing the metapackage.
You then lose the ability to remove all of those games simply by
removing the metapackage.

There is no downside to using Recommends and no upside to using Depends
for metapackages.  I believe that policy should explicitly mention
Recommends as the correct dependency for metapackages.

A metapackage should not be a hammer to beat the user into installing
everything you want them to, it should be a tool to allow the user to
easily select a group of related packages that make sense to install
together.  Any real Depends relationship should be specified in the
sub-packages.  Note that games-finest Depends on games-tasks; this is an
example of correct use of Depends in a metapackage.

...Marvin


-- 
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/20150728120833.gg21...@basil.wdw

Re: Proposal v2: enable stateless persistant network interface names

[Marvin Renich]

* Marco d'Itri m...@linux.it [150625 07:27]:
 On Jun 25, Martin Pitt mp...@debian.org wrote:
 
  Unlike /dev nodes, network interfaces can't have aliases as far as I
  know. Am I missing anything?
 No. As is usual with udev, the people who do not understand how it works 
 are always ready to propose solutions.
 
 -- 
 ciao,
 Marco

I think what some people are missing in this discussion is the relative
importance of two design goals.  In the original message, one of the
stated design goals was to eliminate the state file in /etc (or /var,
which might be a better place for it).  The obfuscated interface names
are a direct result of attempting to achieve that goal.

The goal that wasn't on the list, but should have been, was to have
interface names that a human sysadmin could easily recognize,
distinguish, and type _on the command line_.  This goal is at least an
order of magnitude (I think two orders of magnitude) more important than
eliminating the state file.

Think about it.  Any program can deal with any name or naming
convention.  It doesn't matter whether the name is obfuscated or not.  A
human sysadmin, however, has a much easier time using eth2 than
enx3c52ca.  Binary ids are for programs; short, easy-to-use names are
for humans.

If the priority of the goals is realigned to make sense, then we must
eliminate any solution that satisfies the no-state-file goal if it does
not also satisfy the human-usable goal.  If this brings us back to where
we currently are, so be it.  But please do not add significant cognitive
burden on the humans who must use the interface names just to get rid of
a state file.  Eliminating the state file is not worth it.

(I'm not saying that a solution that satisfies both can't be found, and
if it is found, that's great.  But the current proposal absolutely fails
the human-usable goal.)

...Marvin


-- 
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/20150625121612.gb3...@basil.wdw

Re: Proposal: enable stateless persistant network interface names

[Marvin Renich]

* Marco d'Itri m...@linux.it [150510 23:55]:
 I see a large enough consensus about switching by default to ifnames, 
 and I believe that the few people who want MAC-based names for USB 
 interfaces can easily set NamePolicy=mac or write a custom rule.

Huh?  This thread seems to have lots of opinions on both sides with no
consensus at all.  I don't see how you can make this assertion with a
straight face.

...Marvin


-- 
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/2015051923.gc18...@basil.wdw

Re: Proposal: enable stateless persistant network interface names

[Marvin Renich]

* Martin Pitt mp...@debian.org [150509 05:27]:
 TBH, hotpluggable USB network adapters which change all the time sound
 like a corner case in a server world where you have hand-written
 config files referring to interface names. They are of course common
 on the client side, but there stable interface names don't matter at
 all. But see below.

I disagree that stable interface names do not matter for USB adaptors
for consumer laptops.  I have owned two laptops where the on-board WiFi
adaptor was too new to have reliable Linux drivers until 6-12 months
after I purchased them.  While waiting for the Linux drivers, I used a
USB WiFi dongle that has good kernel support.  I have plugged the
adaptor into different USB ports based on where my laptop was situated
wrt varied surroundings.  I suspect (with no real data to back it up)
that the biggest use of USB WiFi dongles on consumer machines is when
the on-board WiFi doesn't work for some reason (too new or broken).  In
this case, it is often the main internet connection and a stable name is
important.

To address the statement about swapping a new adaptor for a broken
adaptor (in server or client desktop), this happens so rarely and
already requires a significant effort (opening the machine, etc.) that
editing the udev persistent network rules is not an issue.  This does
not make MAC-based names less usable in that context.

I'm not sure what the correct solution is, but from what I have seen in
this thread, I have become convinced that [ifnames] is not it.  (That is
a change from my initial perception.)  I would like to discourage the
proposed change.  Perhaps some compromise where ifnames is used for
PCI-based devices and MAC is used for USB devices might work; I'm not
sure.

I have no problem with learning a new naming convention for the devices.
Note that the naming convention makes no difference for programmatic
use; any programmatic use should query the specific properties of the
device that are important to the program.  The naming convention is only
relevant to the sysadmin, where it helps to identify properties in which
the sysadmin might be interested (e.g. wired vs wireless).

...Marvin


-- 
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/20150509203542.ga18...@basil.wdw

Re: Proposal: enable stateless persistant network interface names

[Marvin Renich]

* Josh Triplett j...@joshtriplett.org [150509 17:37]:
 Marvin Renich wrote:
  I disagree that stable interface names do not matter for USB adaptors
  for consumer laptops.  I have owned two laptops where the on-board WiFi
  adaptor was too new to have reliable Linux drivers until 6-12 months
  after I purchased them.  While waiting for the Linux drivers, I used a
  USB WiFi dongle that has good kernel support.  I have plugged the
  adaptor into different USB ports based on where my laptop was situated
  wrt varied surroundings.  I suspect (with no real data to back it up)
  that the biggest use of USB WiFi dongles on consumer machines is when
  the on-board WiFi doesn't work for some reason (too new or broken).  In
  this case, it is often the main internet connection and a stable name is
  important.
 
 Why?  What does a stable name matter in the case you mentioned?
 
 Were you actually using ifupdown to manage the varied set of wireless
 networks?  Because if not, then the name shouldn't matter.
 
 It doesn't seem that difficult to change the NamePolicy for that case.

Yes, I use ifupdown and wpasupplicant.  Based on some of the threads on
this list there are many people who love Network Manager and many who
dislike it.  I am one of the ones who dislike it.  Given the fact that
it is (or at least was recently) clearly controversial, choosing a path
that relies on its use seems detrimental to me, regardless of whether it
is the default or not.

...Marvin


-- 
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/20150510003557.gb18...@basil.wdw

Re: motd handling in jessie

[Marvin Renich]

* Josh Triplett j...@joshtriplett.org [150126 11:24]:
 Russ Allbery wrote:
  Josh Triplett j...@joshtriplett.org writes:
   However, I don't think run a pile of scripts to write out a dynamic
   MOTD at boot time is a sensible default, either.
  
  Why not?
  
   I'd suggest putting update-motd and update-motd.d into a separate,
   optional package that users can install if they really want it, and
   using either static files or /etc/issue escape sequences as the default
   to avoid running *anything* at either boot or login time.
  
  This desire to avoid running something at boot is mystifying to me.  Since
  when do we try to avoid running things at boot, and why would we?  It's
  not like this is going to add any appreciable delay to boot time (and
  that's not a huge concern anyway).
 
 One more (set of) shell scripts spawned at boot time adds incremental
 complexity, fragility, and yes, a small amount of delay.  It might not
 matter much if you're spending 60 seconds booting a server; on the other
 hand, with client boot times currently at a few seconds without any
 optimization, 1s with a little work, and hopefully heading even lower,
 spawning off even one more instance of /bin/sh than needed (along with
 miscellaneous other programs invoked from a shell script) seems worth
 avoiding.

If we are going to include uname in the motd, /etc/motd must be built
after boot, before the first login.  Cron is not a viable option for
this, and it seems to be agreed that pam is the wrong place to do this,
as well.

If we are talking about the Debian default behavior, I think the pile
of scripts being referred to is a single script that will probably be
as simple as { uname -a ; cat /etc/motd.skel }  /etc/motd.  I think one
shell script invoking two executables is an acceptable price to get
uname in motd.

If we are not talking about the Debian default, then the size of the
pile of scripts is at the discretion of the local sysadmin.

I think you are over-estimating the burden that this will put on the
boot process.  Your boot times of 1s with a little work could easily
include removing the update-motd scripts, and I think Russ' proposed
solution will still give you your few seconds without any
optimization.

...Marvin


-- 
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/20150126195839.ge...@basil.wdw

Re: DE features dependent on Systemd

[Marvin Renich]

* Matthias Urlichs matth...@urlichs.de [141130 09:22]:
 But on a multi-user system, we can't depend on the first user being any
 sort of special owner; it might just as well be the person whose desk
 the machine is hidden under

I strongly disagree with this.  The person performing the installation
clearly has root privileges while the installation is being performed,
and is much more likely to be at least one of the people responsible for
maintaining the system.  While not a universal truth, there is a high
probability that this person will have additional privileges beyond a
normal user, either by the first user being added to extra groups, by
the person doing the installation having root privileges (by knowing the
root password or through sudo), or both.

As for the fallacy that adding the first user to additional groups is a
privacy or security issue, if we can agree that there is at least one
administrator with root privileges, and the first user added by the
installer likely belongs to such a person, what good does it do to not
add the first user to the audio group?  With root privileges, the admin
can do all of the things mentioned in this thread to invade other users'
privacy.  Trying to give a false sense of security by saying we don't
give the first user special privileges, so you don't have to worry about
being spied on remotely is a complete lie.  If you don't trust the
administrators of your machine, then assume they are spying on you;
there is no other reasonable assumption, and refusing to add the first
user to special groups does not change that.

The only case where not adding the first user to special groups would
make a difference is when the person doing the installation for a
machine shared by multiple users asks the installer to add the first
user, but assigns that first user to one of the non-administrators of
the machine.  I think this is extremely rare in practice, in both
business and home settings.

...Marvin


-- 
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/20141204152736.gf3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Ansgar Burchardt ans...@debian.org [140909 11:16]:
 On 09/09/2014 16:59, Russ Allbery wrote:
  I don't believe we should switch init systems on upgrade without at least
  a prompt,
 
 I think there are good arguments for both switching to the new default
 and not:

Perhaps, but not without giving the sysadmin a choice, unless you have
handled all the cases where the sysadmin has modified configuration
files such as /etc/inittab and scripts in /etc/init.d.

...Marvin


-- 
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/20140909190423.gc3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Mathieu Parent math.par...@gmail.com [140909 09:15]:
 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez clo...@igalia.com:
 [...]
  So, when upgrading from Wheezy to Jessie, we have three options:
 
  1) Keep the user init system (sysvinit most probably)
  2) Upgrade to systemd after asking the user.
  3) Upgrade to systemd silently without asking the user.
 
 4) Upgrade to systemd silently without asking the user AND add a grub
 entry to use old init
 
 This will provide the intended default with an extra compatibility
 layer (like the former grub1 to grub2 chain).

Debian packages at least two other families of boot loaders.  I am using
syslinux-efi on one machine, and have used lilo and elilo in the past.
Adding a grub entry will not adequately solve the problem.

...Marvin


-- 
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/20140909185819.gb3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Michael Biebl bi...@debian.org [140909 11:43]:
 Am 09.09.2014 17:15, schrieb Ansgar Burchardt:
  Having only some systems switch to a different init system on upgrade
  seems potentially confusing to me.
 
 Agreed. We definitely should switch the machines on upgrades. There is a
 good reason why we also did it when switching to dependency based boot.

I disagree.  Switching automatically might be okay if the sysadmin has
not made any local modifications to the boot process, or if you can be
sure that systemd is going to do the right thing with the sysadmin's
modifications, but preserving local sysadmin changes has alway been one
of the things that set Debian apart from other distros.  Please don't
mess this up now.

As for dependency based boot, it recognized when it could not handle it
properly (at least on one machine of mine) and fell back to manual
ordering, with an appropriate log message.  ISTR that I had two full
releases after upgrading to dependency based boot before I was forced to
fix it.  If systemd gives that kind of fallback, I will not complain.

...Marvin


-- 
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/20140909191638.gd3...@basil.wdw

Re: let's split the systemd binary package

[Marvin Renich]

* Tollef Fog Heen tfh...@err.no [131024 15:06]:
 ]] Marvin Renich 
 
  I believe that systemd/GNOME upstream is intentionally coupling the two
  in order to force adoption of systemd.
 
 You're aware that GNOME and systemd upstreams are two completely
 distinct groups with (AFAIK) very little overlap between them, right?
 Even if one assume that they are intentionally coupling the two of them
 tightly, I fail to see a motive on the GNOME maintainers.  They have no
 obvious interest in making systemd ubiquitous.

* Olav Vitters o...@vitters.nl [131024 16:12]:
 GNOME is not. And I'm speaking as a GNOME release team member.
 
 A video of GNOME 3.10 running on OpenBSD:
 https://www.bsdfrog.org/tmp/gnome310.webm
 
 A link to the GNOME release team members:
 https://wiki.gnome.org/ReleasePlanning/Membership
 
 Don't think I need to list the main systemd developers.

I was aware that they were separate projects, but was mistakenly under
the impression that there were some key developers who contributed to
both projects.  I was wrong, and you have my apologies for attributing
ulterior motives to you that you do not have.

* Tollef Fog Heen tfh...@err.no [131024 15:06]:
 ]] Marvin Renich 
 
  There are obviously others who do not believe this.  If it is true,
  however, I would consider it sufficient justification to both change
  Debian's default DE and eliminate systemd as a candidate for the
  default init system, regardless of any technical merits.
 
 I have no idea how you get from «GNOME upstream couples their software
 tightly to systemd interfaces» to «systemd should not be a candidate for
 being a default init system».
 
 GNOME upstream makes their own decisions on what interfaces they use.
 They choose to depend on particular interfaces, and they should carry
 the burden for that.  Not the depended-on component.

If my mistaken belief were true, then «systemd should not be a candidate for
being a default init system» would follow from «I do not want the default
init system to be one that is developed by people whom I cannot trust».

However, it is obviously true that systemd as the default init
system is controversial, and that GNOME depends on it.  While GNOME may
work with systemd installed but not PID 1 at the moment, in another
message Uoti Urpala says that systemd as PID 1 will be required in an
upcoming release.  If this is true, regardless of motives, then
if GNOME is the default DE, systemd will be the de facto default init
system.  The default init system should be decided _before_ the DE, not
_by_ the DE.

...Marvin


-- 
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/20131025143630.gl8...@basil.wdw

Re: let's split the systemd binary package

[Marvin Renich]

* Tollef Fog Heen tfh...@err.no [131024 05:39]:
 ]] Steve Langasek 
 
  On Thu, Oct 24, 2013 at 02:21:25AM +0200, Matthias Klumpp wrote:
   2013/10/24 Steve Langasek vor...@debian.org:
[...]
If Gnome depends on gnome-settings-daemon, which now depends on 
systemd,
this might be a worrying trend, as non-Linux kernels don't support 
systemd.
  
Well, that's one more reason the init system and the dbus services 
should be
separated out in the packaging.
   Some of the services consume functions and features provided by
   systemd (the init system).
  
  Which is exactly the kind of embrace-and-extend that Debian should not
  tolerate having foisted on them in the default desktop by an upstream
  pushing an agenda.
 
 I'm arguing for that systemd is a complete package.  You can't just take
 one part of it and expect it to work, at least not without throwing
 engineering time at it as well.

The issue is not whether or not systemd is a complete package, but that
the (current) Debian default desktop environment Depends on systemd.  If
systemd were already established as the _sole_ currently accepted init
system, there might be a reasonable argument for this.  However,
currently, systemd is *very* controversial, and it is extremely unclear
that it will become the default Debian init system.  The default Debian
DE should not require it.

I believe that systemd/GNOME upstream is intentionally coupling the two
in order to force adoption of systemd.  There are obviously others who
do not believe this.  If it is true, however, I would consider it
sufficient justification to both change Debian's default DE and
eliminate systemd as a candidate for the default init system, regardless
of any technical merits.

...Marvin


-- 
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/20131024134948.gk8...@basil.wdw

Re: Have NetworkManager disabled by default when...

[Marvin Renich]

* Michael Biebl bi...@debian.org [120718 17:31]:
 On 18.07.2012 22:54, Matt Zagrabelny wrote:
 
  Why are people not a aware of that update-rc.d interface? Is this a
  general documentation problem?
  
  I've been under the impression that future upgrades to the package
  would re-enable the symlinks whereas /etc/default is not touched by
  upgrades.
 
 No, this is not true.
 
 You are probably thinking of update-rc.d service remove, which
 simply removes the start symlinks, wheres disable renames them from S??
 to K??. This change is preserved during upgrades and invoke-rc.d
 correctly handles such services and does't try to start them when
 disabled this way.

While update-rc.d service disable correctly disables a service, what
most sysadmins want (or so I believe) when they disable a service in
this manner is to put the service in manual mode, which this does not
do, at least not completely.  In manual mode, changes to the runlevel,
other than halt and reboot, do not stop or start that service.  The
above command only acts as manual mode as long as the system never
changes runlevel.

To correctly put the service in manual mode you must manually remove the
symlinks from runlevels S 2 3 4 5, leaving the K symlinks for runlevels
0 and 6.  update-rc.d will not do this, as its remove command will only
remove _all_ symlinks, and is really only intended for postrm scripts on
package purge.

...Marvin


-- 
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/20120719111929.gg5...@cleo.wdw

Re: Migration path for 'Multi-Arch:allowed' packages

[Marvin Renich]

* Ben Hutchings b...@decadent.org.uk [120613 23:56]:
 On Wed, 2012-06-13 at 12:47 +0100, Wookey wrote:
  I added a user-oriented HOWTO to the multiarch doc-collection last
  month as there seemed to be a shortage of such docs to point to that
  weren't cryptic specifications, or talking mostly about
  cross-building. It may be a useful place to point people, or just lift
  the good bits from it:
  
  http://wiki.debian.org/Multiarch/HOWTO

Very nice!  Thanks.

 That's quite good, but for release notes I think we would need something
 that more tersely explains what multiarch means and that you *must*
 enable it if you have certain packages installed on certain
 architectures.

Also, please be explicit about what it means to enable multiarch in
this context.  I presume, but am not certain, that it means to add the
correct foreign architecture (i386 in the case of wine-unstable?),
modify sources.list if needed, and do aptitude update (or equivalent).
If this is wrong or I am missing a step, I would appreciate
enlightenment!

...Marvin


-- 
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/20120614144809.ga13...@cleo.wdw

Re: RFC: OpenRC as Init System for Debian

[Marvin Renich]

* Thomas Goirand z...@debian.org [120511 04:45]:
 On 05/11/2012 04:04 AM, David Weinehall wrote:
 From: http://en.wikipedia.org/wiki/Configuration_file
 
 In computing, configuration files, or config files configure the initial
 settings for some computer programs. They are used for user applications,
 server processes and operating system settings.
 
 The fact that these files are in /lib and shouldn't be touched by the admin
 doesn't make them less configuration files. They still match the above
 definition from Wikipedia.
 
  And debian-policy isn't set in stone.
  Otherwise it wouldn't have last been revised in February 2012 :)

 
 The debian-policy maybe, but the FHS, and config files in /etc *is* a very
 strong policy that you will not change in Debian, and for very valid
 reasons already described in this thread.

The FHS is very specific that /etc is for *Host-specific* system
configuration, not upstream defaults or distribution-specific
configuration.  The clear intent is that this is where files that are
intended to be modified by the local system administrator are placed.
Files containing distribution-specific defaults, whether they match some
definition of configuration file or not, do not belong here unless the
they are also intended to be edited by the local sysadmin.

Using a Wikipedia definition must be done with careful consideration, as
they are often either over generalized or too specific.  In this case I
believe the Wikipedia definition is not in the least relevant to the
subtleties being disputed here.

Debian policy does not explicitly differentiate between host-specific
configuration and Debian-provided default configuration, but it does
say, Typically, configuration files are intended to be modified by the
system administrator (if needed or desired) to conform to local policy
or to provide more useful site-specific behavior.

Following the FHS is, however, a must in Debian policy except where
policy explicitly provides an exception or conflicts with the FHS.

It is clear to me that etc-overrides-non-etc is perfectly compliant with
Debian policy as long as the sysadmin does not need to modify the
non-etc files to obtain the desired behavior.

I have been using Debian since 1998, and IME the cases where changes to
the Debian-supplied configuration files would have caused breakage if
the Debian defaults had been in /usr/lib/package and only local
modifications were in /etc have been rare.  On the other hand, the cases
where this model would have both obviated the need for a manual merge
and resulted in exactly the configuration I intended are extremely
common.

Gergely Nagy has shown elsewhere in this thread that no matter which
configuration model you use, there are cases where you might not get a
notification of incompatible default configuration from dpkg on upgrade.
On the other hand, the etc-overrides-non-etc model significantly
simplifies most of the common default-configuration-change cases.

For clarity, the etc-overrides-non-etc model that I am talking about is
where the file in /etc can override individual values, not where the
file in /etc must replace the entirety of the non-etc configuration.

While I agree that etc-overrides-non-etc may not be the best model for
all software, it is the best for some and at least as good for many
other packages.

...Marvin


-- 
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/20120511150832.ga7...@cleo.wdw

Re: RFC: OpenRC as Init System for Debian

[Marvin Renich]

* Steve Langasek vor...@debian.org [120511 16:17]:
 On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
  The FHS is very specific that /etc is for *Host-specific* system
 
 No, this is a total retcon.  When the FHS was written, this was definitely
 NOT a shared understanding of a difference between host-specific
 configuration and upstream defaults / distribution-specific
 configuration.

I obviously read more into host-specific than was intended.

 Distribution defaults still would go in /etc whenever it was expected that
 an admin might want to edit the file.  This has been the convention for more
 than a decade.

Agree completely.  See the next sentence.

  Files containing distribution-specific defaults, whether they match some
  definition of configuration file or not, do not belong here unless the
  they are also intended to be edited by the local sysadmin.
 
 Yes.  The issue is not that either system is a violation of the standard,
 because intent is relevant here.  If the upstream *intends* the file to be a
 template that's overridden using a separate file, then /usr is the right
 place.  If the upstream intends the user to edit the provided file to make
 their changes, it belongs in /etc.  If the defaults are built into the
 binary, that's perfectly fine too.

I agree completely.  I was responding specifically to the assertion that
the definition of configuration file from Wikipedia meant that Debian
must put files containing distribution-specific defaults in /etc,
regardless of whether or not they were intended to be modified by the
local sysadmin.

 What *is* an issue is when upstreams decide to ship their defaults in /usr,
 but require users to duplicate information between /usr templates and /etc
 config files and ignore the contents of /usr in favor of the contents of
 /etc.  This is also not a violation of FHS, but it IS a crappy design.

Again, I agree completely.  See the part of my message that you did not
include where I clarified to which etc-overrides-non-etc model I was
referring.

 When software is not able to override configuration *settings* with fine
 granularity via /etc, the entire thing should go under /etc.  Doing
 otherwise makes this horrible for upgrades.

Absolutely.  Again, see my clarification of how I was using
etc-overrides-non-etc.  I did not go into what I think is wrong with
default in /usr, copy entirety to /etc and edit in order to override a
single setting because I was specifically trying to address the other
poster's assertion that placing anything that matches the Wikipedia
definition of configuration file anywhere other than /etc was a
violation of a must in Debian policy.

...Marvin


-- 
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/20120511210825.gc7...@cleo.wdw

Re: Multiarch file overlap summary and proposal

[Marvin Renich]

* Russ Allbery r...@debian.org [120214 01:48]:
 If this is comprehensive, then I propose the following path forward, which
 is a mix of the various solutions that have been discussed:

I thought Goswin's suggestion in [1] of having dpkg use implicit
diversions has merit and deserves further scrutiny.  It essentially
implements refcnt-like behavior by using the existing diversion
mechanism.  I did not see any message in the thread that even
acknowledged that part of his message.  Did I miss something?

...Marvin

[1] http://lists.debian.org/debian-devel/2012/02/msg00511.html


-- 
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/20120214151437.ga14...@cleo.wdw

Re: directory under /usr/bin -- Ok or not?

[Marvin Renich]

* Stig Sandbeck Mathisen s...@debian.org [07 09:55]:
 Josselin Mouette j...@debian.org writes:
 
  We already have $pkglibdir and $pkgdatadir for those. There is no
  technical need for a new directory in /usr, and it doesn’t improve
  anything for users.
 
 Possibly not for the users, but it _certainly_ improves the environment
 for system and application administrators.
 
 Some applications (for instance: inn and mailman) have a lot of
 executables which only makes sense when you're in the context of that
 application user, so having a /usr/libexec/package in the path for
 that user makes life as an application administrator easier.

How is /usr/libexec/package better than /usr/lib/package in these
cases?

...Marvin


--
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/2007172734.gb4...@cleo.wdw

Re: / vs. /usr vs. fsck(8)

[Marvin Renich]

* Holger Levsen hol...@layer-acht.org [111014 07:49]:
 On Donnerstag, 13. Oktober 2011, brian m. carlson wrote:
  If / and /boot are the same filesystem, then using a filesystem that the
  bootloader supports is important.  At least in the recent past, grub 2
  didn't support booting off ext4; there was some problem when doing that.
  If /usr is a separate filesystem, I can use ext4 there and leave / ext3.
 
 just two days ago I installed a system with no /boot partition, and / und 
 /usr 
 on ext4. Booted fine with grub2. / is a raid1.

I think the point Brian is trying to make is not whether or not this
particular case works, but that new filesystems are occasionally
developed and put into use, and there is usually a point where the new
filesystem is ready for extensive use on non-mission-critical systems by
a larger user base, but is not fully supported by boot loaders and/or is
not quite stable enough to trust as a root filesystem for recovery
purposes when the occasional glitch does happen.

(Though it is good to know that grub 2 supports ext4.)

...Marvin


-- 
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/20111014131754.ga11...@cleo.wdw

Re: aptitude weirdness wrt upgrades and keeps

[Marvin Renich]

* Miles Bader mi...@gnu.org [111014 03:04]:
 Paul Wise p...@debian.org writes:
  Not a solution for the interactive mode, or am I wrong?
 
  Not AFAICT, I only read the documentation rather than the code though.
 
 Kinda surprising, actually; this has long been the #1 most horrible
 thing about aptitude, and one about which there's been plenty of
 complaining...
 
 [With the normal U command, for my typical usage, aptitude seems to
 choose the worst possible solution about 98% of the time.]

You can use aptitude safe-upgrade --visual-preview, though this is not
particularly convenient when already running the aptitude cua.

You can also check out Aptitude::Always-Use-Safe-Resolver.

I, too, find that the priorities given to the resolver's solutions and
the action I intended are often quite disparate.  The above remedies can
be helpful, but are not real solutions.

...Marvin


-- 
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/20111014141322.gb11...@cleo.wdw

Re: Writing to /etc/ from a privileged UI

[Marvin Renich]

* David Paleino da...@debian.org [110509 04:19]:
 On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote:
 
  /etc may include only _static_ configuration.  What you have is variable
  state which belongs in /var.  It's no different from a database, or dpkg's
  status data.
 
 Static IPs, DNS servers and WEP/WPA keys for a given wireless network are
 variable state? Sorry, I disagree.
 
 I already said that I have a patch not to save networks for which no
 configuration is made -- which is the variable state thing at the moment. 
 The
 question was different :)

This isn't about whether the data saved in the config file is variable,
it is about whether the config file is variable.  Files in /etc should
only be modified when the sysadmin is doing what (s)he considers to be
configuration, not when a user is running a program.

The specific data shown in the bug report is clearly variable state
information and not static configuration info, but even adding and
removing more permanent wireless access point info should not be done in
/etc during the normal, continuous operation of a daemon.

If I were designing the config structure, since each AP is a distinct
entity that doesn't depend on any other AP (maybe that should be essid,
not AP), I would have a .d directory where each essid had its own config
file.  There could be corresponding /etc/wicd/something.d and
/var/lib/wicd/something.d directories.  The admin could place files in
/etc that he didn't want users messing with.  Non-conflicting files in
/etc, /var/lib, and ~user/.wicd (or better, ~user/.config/wicd), would
be treated equally by wicd, with preference to ~user/.config/wicd then
/var/lib/wicd, then /etc/wicd for any conflicting entries.

Actually, one normal user should not be able to override the admin
defaults for another user, so if there is already an entry in /etc, wicd
should place any user change to that entry in ~user, but new,
non-conflicting entries should go in /var/lib.  Then, the order of
preference should be ~user, /etc, /var/lib.

Transient state information, like signal strength and quality should
_not_ go in these files, but rather in /var/run/wicd/ (soon to be
/run/wicd/).

...Marvin


-- 
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/20110509134541.gb...@cleo.wdw

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

[Marvin Renich]

* Luca Capello l...@pca.it [110414 06:43]:
 Hi there!
 
 Disclaimer: this is my last post on this matter (i.e. the meaning of
 RAMLOCK), it seems there is a problem with myself or my understanding.
 
 Either I do not read `man rcS` as you read it or we do not understand
 each other, so here the situation before and after your patch for /run
 (/var/lock became useless, everything is in /run/lock now, but I kept
 using /var/lock for consistency with the previous state):
 
 [before] RAMLOCK=no  - /var/lock on the same filesystem /var is on
  RAMLOCK=yes - /var/lock on tmpfs
  [after] RAMLOCK=no  - /var/lock is on tmpfs, shared with /run (given
 that /var/lock is symlinked/bind-mounted to
 /run/lock)
  RAMLOCK=yes - /var/lock gets its own tmpfs, differently from
 the one mounted at /run
 
 So, the meaning of RAMLOCK, WRT `man rcS` and as I read it, *has*
 changed.  This is where we do not agree on wordings, but given that
 English is not my mother language, maybe it is only my fault.
 
 Thx, bye,
 Gismo / Luca

Luca,

It appears to me that you understand perfectly what RAMLOCK does.  Your
issue appears to be with the wording of the man page.  To me (as a
native English speaker) the wording is explicit about what will happen
if you set RAMLOCK=yes (i.e. a tmpfs will be allocated and mounted at
/var/lock--soon to be /run/lock), but is ambiguous as to what will
happen if RAMLOCK=no.  The implicit meaning is that no tmpfs will be
allocated _for /var/lock_ and it will be on the same file system as
/var, whatever that may be (soon to be /run/lock and /run).  So the
implicit behavior is that if RAMLOCK=no, and /var is a tmpfs, /var/lock
will simply be a part of the tmpfs on /var.  This is indeed the current
(pre-/run) behavior, and is exactly the same as what will soon be with
/run.

The current wording of the man page seems correct to me, even for the
new /run directory structure (with appropriate changes from /var/lock to
/run/lock), but some minor changes in wording would make the RAMLOCK=no
behavior more explicit.  I would add the word separate and a sentence
describing the behavior when RAMLOCK=no:

Make /var/lock/ available as a separate ram file system (tmpfs).
Will also disable cleaning of /var/lock/ during boot.  Set to 'yes'
to enable, to 'no' to disable.  When 'no', /var/lock is on the same
file system as /var.  The size of the tmpfs can be controlled using
TMPFS_SIZE and LOCK_SIZE in /etc/default/tmpfs.  Because of this,
packages can not expect directories in /var/lock to exist after
boot.  Packages expecting this are buggy and need to be fixed.

If you like this wording, you should file a wishlist bug on the
initscripts package.  (I'm not going to because the current wording
doesn't bother me.)

...Marvin


-- 
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/20110414132723.ga3...@cleo.wdw

Re: potential MBF: first alternate depends not available in main

[Marvin Renich]

* Carsten Hey cars...@debian.org [110304 06:17]:
 * Paul Wise [2011-03-04 12:54 +0800]:
  Debian Policy section 2.2.1 already covers this:
 
  ...the package must not declare a Depends, Recommends, or
  Build-Depends relationship on a non-main package.
 
  http://www.debian.org/doc/debian-policy/ch-archive.html#s-main
 
 This can be read in different ways:
 
  * All of the alternatives must be in main.
  * The first alternative must be in main.
  * One of the alternatives must be in main.

From an English language POV, the quote above (taken out of context)
clearly forbids any alternative in a Depends or Recommends from being
outside of main.

Here is the quote with enough context to show that the intent was
otherwise and that other interpretations are reasonable:

...the packages in main

   • must not require a package outside of main for compilation or
 execution (thus, the package must not declare a Depends,
 Recommends, or Build-Depends relationship on a non-main
 package)

I am not a DD or an expert on policy, but I would interpret the
parenthetical to be explanatory rather than normative.

Here is a suggested wording to clarify the parenthetical:

...the packages in main

   • must not require a package outside of main for compilation or
 execution (thus, all declared Depends, Recommends, and
 Build-Depends relationships must be satisfiable with only
 packages in main)

I will file a wishlist bug against policy if there are no objections.

...Marvin


--
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/20110304154535.ga3...@cleo.wdw

Re: potential MBF: first alternate depends not available in main

[Marvin Renich]

* Scott Kitterman deb...@kitterman.com [110304 10:01]:
 Seems reasonable to me.

Bug filed: #616462

...Marvin


-- 
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/20110304174703.ga3...@cleo.wdw

Re: UPG and the default umask

[Marvin Renich]

* Bastien ROUCARIES roucaries.bast...@gmail.com [100520 08:30]:
 reopen 315089
 thanks
 
 Closed by maintener and reopened, if we use libpam for umask it could
 be even raised to RC critical, so please correct this behavior, report
 upstream. I agree that it could be misleading for other distro in this
 case, please add a newoption like useupg.
 
 Thanks
 
 Bastien

I have forwarded this upstream.
https://sourceforge.net/tracker/?func=detailatid=106663aid=3004656group_id=6663

...Marvin


-- 
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/20100520124737.gb4...@cleo.wdw

Re: APT do not work with Squid as a proxy because of pipelining default

[Marvin Renich]

* Robert Collins robe...@robertcollins.net [100517 22:03]:
 Given that pipelining is broken by design, that the HTTP WG has
 increased the number of concurrent connections that are recommended,
 and removed the upper limit - no. I don't think that disabling
 pipelining hurts anyone - just use a couple more concurrent
 connections.
 
 -Rob

I was unaware that pipelining was considered broken by design, so I
was trying to say that if there was an easy way for apt to choose
between pipelining and no pipelining (if it wasn't specifically set by
the admin) that would handle most of the cases, that was better than
disabling by default a feature that was beneficial to many.

If pipelining is considered broken, and concurrency is preferred, I'm
perfectly happy with that.

...Marvin


-- 
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/20100518120244.gl1...@cleo.wdw

Re: APT do not work with Squid as a proxy because of pipelining default

[Marvin Renich]

* Goswin von Brederlow goswin-...@web.de [100518 02:53]:
 Marvin Renich m...@renich.org writes:
  Documenting this problem somewhere that an admin would look when seeing
  the offending Hash sum mismatch message would also help.  Turning off
  pipelining by default for everybody seems like the wrong solution to
  this problem.
 
  ...Marvin
 
 Maybe apt should check size and try to resume the download. I'm assuming
 it gets the right header but then the data ends prematurely?
 
 Could you try to capture a tcpdump of the actual traffic between apt and
 the proxy?
 
 MfG
 Goswin

Fortunately, I am not behind a proxy, so I can't check this.  :-)

...Marvin


-- 
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/20100518120413.gm1...@cleo.wdw

Re: UPG and the default umask

[Marvin Renich]

* Reinhard Tartler siret...@debian.org [100517 08:56]:
 Let's have a look at the source. Note that options-usergroups is set
 iff the option usergroups is used.
 
 ,[modules/pam_umask/pam_umask.c]
 | /* Set the process nice, ulimit, and umask from the
 |password file entry.  */
 | static void
 | setup_limits_from_gecos (pam_handle_t *pamh, options_t *options,
 |  struct passwd *pw)
 | {
 |   char *cp;
 | 
 |   if (options-usergroups)
 | {
 |   /* if not root, and UID == GID, and username is the same as
 |  primary group name, set umask group bits to be the same as
 |  owner bits (examples: 022 - 002, 077 - 007).  */
 |   if (pw-pw_uid != 0  pw-pw_uid == pw-pw_gid)
 | {
 |   struct group *grp = pam_modutil_getgrgid (pamh, pw-pw_gid);
 |   if (grp  (strcmp (pw-pw_name, grp-gr_name) == 0))
 | {
 |   mode_t oldmask = umask (0777);
 |   umask ((oldmask  ~070) | ((oldmask  3)  070));
 | }
 | }
 | }
 `
 
 This part of pam seems to match the documentation in pam_umask(8).
 
  And it was said in this thread that UID == GID is not always true with
  UPG. You only need to create a group for that to become false for users
  you would create afterwards.
 
 I'd say if Debian's idea of UPG doesn't match pam's, we should either
 change the pam implementation or the implementation of Debian's UPG
 concept to match each other.
 
 In any case, using pam_umask by default seems to the best approach so far.

This looks like a bug in pam_umask.  UPG has never guaranteed uid=gid.
I'll file a bug.

...Marvin


-- 
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/20100517133405.gf1...@cleo.wdw

Re: UPG and the default umask

[Marvin Renich]

* Aaron Toponce aaron.topo...@gmail.com [100517 13:05]:
 On 05/17/2010 10:49 AM, Harald Braumann wrote:
  from pam_umask's description of the usergroups option:
  
  If the user is not root, and the user ID is equal to the group ID, *and*
  the username is the same as primary group name, the umask group bits
  are set to be the same as owner bits (examples: 022 - 002, 077 -
  007). 
  
  So if there is a mismatch of *either*, name or ID, then pam_umasks
  detects a non-UPG system, while it might very well be all UPG.
 
 A bug in pam_umask.so that needs to be addressed (which I believe we've
 already started addressing in this thread).

Bug #581984.

  Also,
  just because Debian's adduser happens to give the same name to the
  user as well as to his private group, this is not necessarily true in
  all system. You could have group names that are prefixed with grp,
  or whatever, but still have a perfectly valid UPG system.

Then you must have manually configured the system, and you need to
manually configure PAM or /etc/profile or whatever to address all the
issues of your deviation from _defaults_.

Out of the box, Debian (we are not discussing other distros) uses UPG
and always uses the username for the name of the UPG assigned to that
user, unless you manually select a different group name, at which point
we are back to the point about an admin who deviates from defaults needs
to be aware of the consequences.

...Marvin


-- 
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/20100517210507.gj1...@cleo.wdw

Re: APT do not work with Squid as a proxy because of pipelining default

[Marvin Renich]

* Robert Collins robe...@robertcollins.net [100517 17:42]:
 Due to the widespread usage of intercepting proxies, its very hard, if
 not impossible, to determine if a proxy is in use. Its unwise, at
 best, to assume that no proxy configured == no proxy processing your
 traffic :(.
 
 -Rob

IANADD, but if I had filed bug #56, I would have selected severity
critical (makes unrelated software on the system break), and similarly
for any other transparent proxy in Debian that fails to work
transparently.

The proxy may not be on a Debian system, but wouldn't the following
logic in apt catch enough of the problem cases to be a useful
workaround:

If Acquire::http::Pipeline-Depth is not set and Acquire::http::Proxy
is set, use 0 for Pipeline-Depth; use current behavior
otherwise.

Documenting this problem somewhere that an admin would look when seeing
the offending Hash sum mismatch message would also help.  Turning off
pipelining by default for everybody seems like the wrong solution to
this problem.

...Marvin


-- 
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/20100518002527.gk1...@cleo.wdw

Re: The 'git' Debian package in squeeze

[Marvin Renich]

* Gerrit Pape p...@smarden.org [090917 05:18]:
 Hi,
 
 thanks to Ian Beckwith, the GNU Interactive Tools package 'git' has been
 renamed to 'gnuit' in lenny.  In lenny 'git' is a transitional package
 that depends on gnuit, in squeeze and sid there's no 'git' package
 anymore.
 
 I'm about to provide a new git binary package from the git-core (the
 distributed revision control system) source, so that 'apt-get install
 git' installs the git content tracker in squeeze.  For people upgrading
 from lenny with git (from gnuit) installed, this means the new git (from
 git-core) package will be installed even if git-core wasn't installed
 before.  I don't think it's that bad, should it be documented in
 NEWS.Debian in the new git package nevertheless?
 
 Thanks, Gerrit.

IANADD, but as a user I think you should wait one release before reusing
an old package name for a different package.

Let me say that this specific case does not affect me; I already use
git-core, so there would be no issue for me with an upgrade changing
packages.

But, if I were a gnuit user and not a git-core user, I would find it
annoying (and possibly confusing) when upgrading from lenny to squeeze
to have a new package added that I didn't want and that is completely
unrelated to anything I had already installed simply because a more
popular package wanted to take over the name of a different package that
I was using.

There is also the package version issue.  If the new git (from git-core)
keeps the epoch, then there won't be an issue, as the old git (gnuit)
did not have an epoch.  But in the general case, thought should be given
to any effects of the version numbers of the defunct package compared
with the version of the new, unrelated package with the same name.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The 'git' Debian package in squeeze

[Marvin Renich]

* Leandro Doctors ldoct...@gmail.com [090917 10:41]:
 2009/9/17 Marvin Renich m...@renich.org:
  But, if I were a gnuit user and not a git-core user, I would find it
  annoying (and possibly confusing) when upgrading from lenny to squeeze
  to have a new package added that I didn't want and that is completely
  unrelated to anything I had already installed simply because a more
  popular package wanted to take over the name of a different package that
  I was using.
 Perhaps including the version in the dependency helps?
 
 After all:
 if version(git) = LENNY_GIT_VERSION -- git == GNU Interactive Tools
 if version(git)  LENNY_GIT_VERSION -- git == Git Version Control
 System and Friends
 
 Right?
 
 L
 (IANADD)

Adding the version to which dependency?  How does that prevent
git(lenny) being upgraded to git(squeeze)?

gnuit already Conflicts and Replaces git ( 4.9.2-1).  It also Provides
git.  This Provides should, I believe, be removed for either squeeze or
squeeze+1.  But there is a dummy (real) package git 4.9.4-1 in lenny.
If aptitude (and other package managers) remove git automatically when
upgrading from etch to lenny, then my objection is void, since lenny
users will not have git installed unless they explicitly installed the
dummy package.  But if the upgrade causes both git 4.9.4-1 and gnuit
4.9.4-1 to be installed, then squeeze gnuit should conflict and replace
git ( 4.9.5) so that anyone upgrading to squeeze will have git removed
automatically, and the upgrade to squeeze+1 will not bring in git(-core)
gratuitously.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The 'git' Debian package in squeeze

[Marvin Renich]

* Vincent Danjean vdanjean...@free.fr [090917 11:05]:
 There is no way APT (or dpkg) knows that git/lenny should be remove
 instead of being 'upgraded' in git/squeeze.
 
 Note that adding a release (squeeze) without a git package will not
 solve the problem: the git/lenny package will not be removed from
 the system without an explicit action of the administrator.
 And the administrator can already remove the empty git/lenny package.
 
   I cannot see a good solution here.

If gnuit(squeeze) Conflicts and Replaces git ( 4.9.5) and squeeze does
not have git, then git will be removed on upgrade to squeeze (there is
no git = 4.9.5).

I do not know how aptitude deals with the automatic/manual flag in this
case, though.  Suppose a user has etch installed with git 4.3.20-10
(marked as manual in aptitude).  The upgrade to lenny will bring in
gnuit 4.9.4-1; I think aptitude will mark it automatic, but I am not
clear how aptitude handles the automatic flag when dealing with a
package that both Conflicts and Replaces a dummy transitional package.
If gnuit(squeeze, currently 4.9.5-1) Conflicts and Replaces git (
4.9.5), the dummy transitional package will be removed, but since (in
the simple case) nothing else depends on gnuit and it is still marked
automatic, it will also be removed.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The 'git' Debian package in squeeze

[Marvin Renich]

* Marvin Renich m...@renich.org [090917 11:40]:
 I do not know how aptitude deals with the automatic/manual flag in this
 case, though.  Suppose a user has etch installed with git 4.3.20-10
 (marked as manual in aptitude).  The upgrade to lenny will bring in
 gnuit 4.9.4-1; I think aptitude will mark it automatic, but I am not
 clear how aptitude handles the automatic flag when dealing with a
 package that both Conflicts and Replaces a dummy transitional package.
 If gnuit(squeeze, currently 4.9.5-1) Conflicts and Replaces git (
 4.9.5), the dummy transitional package will be removed, but since (in
^ on upgrade to
  squeeze
 the simple case) nothing else depends on gnuit and it is still marked
 automatic, it will also be removed.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Change user used by package

[Marvin Renich]

* Harald Braumann ha...@unheit.net [090113 16:49]:
 On Tue, 13 Jan 2009 12:57:11 -0800 Steve Langasek vor...@debian.org wrote:
  If they remove the user on purge, that should be changed anyway.
 
 Well, jabber-common does remove the user jabber on purge, jabberd2,
 though, doesn't. And it seems that opinions diverge on this matter. See
 e.g. http://lists.debian.org/debian-mentors/2004/10/msg00338.html.

I've filed a bug against jabber-common.  Though the thread started
without a consensus, it ended with a clear consensus that the user
should not be removed.

 I think I take the easy way out. I'll use the user jabber (create it,
 if it doesn't exist) and don't delete it. I'll also add a conflict to
 jabber-common. If that's a problem for someone, a more sophisticated
 solution can still be implemented.
 
 Cheers,
 harry

Why do you need to conflict with jabber-common?  Both can use the same
user, unless there is a security issue and you don't want executables
from jabber-common to be able to read your config files, in which case
you should use a different user anyway.  Was there another reason
independent of the user issue?

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Change user used by package

[Marvin Renich]

* Harald Braumann ha...@unheit.net [090113 05:47]:
 Hi,
 
 I'd like to package mu-conference 0.7 (multi-user chat component for
 jabber). The version currently in Debian (jabber-muc 0.6.0) uses the
 user ``jabber'', which is created by jabber-common, on which
 jabber-muc depends.
 
 The new version can be installed stand-alone, and thus there won't be
 any dependence on jabber anymore, or jabberd2, for that matter. 
 
 AFAIK, there's no way for multiple independent packages for using the
 same user. So jabber-muc needs to create its own user. On update,
 that's no problem. The post-install script can chown the
 package's directories for the new user. But a downgrade would then not
 be possible. The old version couldn't access the directories.
 
 Is there precedence for such a situation? How can it be resolved?
 
 Cheers,
 harry

BTW, are you coordinating this with the current jabber-muc maintainer
(CC'ed in case he is not subscribed)?

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Change user used by package

[Marvin Renich]

(I'm subscribed, no need to CC me.)

* Jamin W. Collins jcoll...@asgardsrealm.net [090114 14:09]:
 I'm not subscribed, haven't been following the lists for a while.  The
 old package should probably be removed completely in favor of the new.

That's fine.  I didn't know the state of jabber-muc, and didn't see any
indication that Harald Braumann was coordinating with you, so I thought
I would mention it.

 However, more to the point, I don't see why the two packages couldn't
 use the same user.  Why not check during installation to see if the user
 account exists?  If it does, use it.  If not create it?

That is the conclusion reached by the thread, but it won't work if
jabber-common removes the user during purge.  Having the new package
conflict with jabber-common won't work, either, as pointed out
previously in this thread (and is against policy, anyway, IIUC).

The only reason I am involved in this thread is that because of it, I
noticed that jabber-common was going to remove its user on purge, and I
think that is a bug (that will affect me), so I reported it.  IANADD,
but a number of DD's have the same opinion.

...Marvin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: RFC: update-rc.d script disable|reenable

[Marvin Renich]

* Michael Biebl [EMAIL PROTECTED] [080924 02:09]:
 
 If you rename all symlinks to K??, as the patch does, you will get such
 a behaviour.
 I.e. when you boot your system, the service will not be started
 automatically. It also won't be stopped or started when you change a
 runlevel, even if you have started it manually.
 
 Yeah, maybe the terms automatic and manual are clearer for what is
 actually happening.
 
 Michael

There are two things wrong with that.  First, not stopping a service
when both the new and previous runlevels have a K link is an explicit
optimization, not the defined behavior.  The traditional definition of a
K link was to kill the service when changing to that runlevel if the
service was running.  Second, it loses information about whether the
original link was S or K.

Prepending ~ (or some other character) allows temporarily suspending
the automatic runlevel handling of that service, and then restoring it,
including restoring any customization done by the sysadmin.

This also has the distinct advantage that a directory listing for a
single /etc/rc#.d gives clear information about what is intended for
that service.  Was the service disabled, or is it supposed to be stopped
at this runlevel?

...Marvin

P.S.  I am subscribed; please don't CC me when replying to the list.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: RFC: update-rc.d script disable|reenable

[Marvin Renich]

* Michael Biebl [EMAIL PROTECTED] [080922 14:43]:
 Kel Modderman wrote:
  Hi all,
  
  This email describes an extension of update-rc.d to provide an interface
  for disabling and reenabling initscript sysvinit runlevel start links.
  
 
 Hi again,
 
 thinking more about it, I think a function is-enabled would be quite
 handy.
 This would allow to query the init system in a defined way, if a given
 service is enabled or disabled.
 
 Another idea would be, to define a new update-rc.d function called
 status, which would return either running, not running or disabled.
 There were some efforts recently, to add a status action to the init
 scripts, which would be a prerequiste of such a new interface to work
 properly.
 
 Cheers,
 Michael
 

I don't think disabling and enabling a service is the right paradigm.
What I want, when I am fiddling with services, is to switch between
automatic and manual.  In automatic mode, changes in runlevel do the
traditional starting and stopping of services based on the symlink farm
or runlevel.conf.  When a particular service is in manual mode, changes
in runlevel should do _absolutely nothing_ to that service (with the
obvious exception for runlevels 0 and 6).

If you implement manual mode, but not disabling, you can easily get
the disabling behavior by switching to manual mode, stopping the
service, and then simply not starting it again.  On the other hand, it
is difficult to get the manual behavior if only disabling is
implemented.  If you disable a service, then start it manually, then in
order to change runlevel without killing the service you must
temporarily fiddle with the symlinks (or runlevel.conf).

The only case that disabling does better is if you want to disable a
service, start it manually, then have it automatically stop whenever the
runlevel changes.  I have never found a use for this behavior.

I think that manual mode can be implemented for the symlink farm by
renaming the symlink to have a leading character other than S or K (e.g.
~); do not replace the S or K, prepend the ~.  For runlevel.conf
(file-rc), it should be as simple as putting a leading #~ on the lines
for that service.  update-rc.d can be made to recognize these changes
and behave accordingly.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Not stopping daemons, where are we?

[Marvin Renich]

* Peter Samuelson [EMAIL PROTECTED] [080705 02:37]:
 
 [Marvin Renich]
  If the package does need to save state, don't enable the quick halt
  option!  The maintainer definitely ought to know this.
 
 Why are all of you talking as though sending SIGTERM were not the
 standard way to tell a process to save its state and exit gracefully?
 It's certainly the method I would use if I were writing a program that
 needed to do things at exit time.  I thought everyone did it that way.

In addition to Steve's response, there is also the issue of ordering.
Some packages (by design or sysadmin configuration) require other
services to be running during their shutdown.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Not stopping daemons, where are we?

[Marvin Renich]

* Bernd Eckenfels [EMAIL PROTECTED] [080703 09:57]:
 In article [EMAIL PROTECTED] you wrote:
  The Debian maintainer for a specific VPN decides it does not need
  special shutdown handling
 
 Nono, thats not my point. My point is, that a maintainer of any package
 cannot easyly forsee which part of the system he is using (resolver, pam,
 proxy, ..) might depend on a daemon - at a specific user's installation.
 
 The downside might be regular unexpected errors at shutdown like host not
 found. Those should be catched/ignored, but you never know.
 
 This might not be a problem (because I also dont have real examples) but,
 then again - its good to talk about it.
 
 Gruss
 Bernd
 

If you are saying that the maintainer of SuperVPN, who is trying to
decide whether or not to mark his package as use killall5 instead of
the initscript when halting, may not know whether certain services used
by the package are provided by daemons that may have already shut down,
my answer is that the maintainer most likely does (and should) know
that, but it is irrelevant.

The relevant question (pertaining to how other packages affect the
quick halt option of this package) is, if services that might be
needed by this package are shut down between the time the sysadmin asks
for a halt and the time this package actually exits, will it adversely
affect user or sysadmin data?  That is, does the package need to save
some data or state to disk (or to another daemon), and are certain
daemons needed for that purpose?

If the package is not trying to save any state, it doesn't matter that
the package normally queries a DNS server that might not respond; the
sysadmin has already said to shut down.

If the package does need to save state, don't enable the quick halt
option!  The maintainer definitely ought to know this.

A caching DNS server is an example of a daemon that might very well
benefit from the quick halt option.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Not stopping daemons, where are we?

[Marvin Renich]

* Bernd Eckenfels [EMAIL PROTECTED] [080701 20:45]:
 In article [EMAIL PROTECTED] you wrote:
  I mean the pending-write case is the most obvious. But what about resolver
  caches, VPNs and the like?
  
  What kind of data loss do you expect to arise from shutting down a VPN
  client without giving it time to save state?
 
 I dont expect any data loss - hopefully protocols are not that
 optimistic/broken. But with unclean shutdown you can affect external parties
 with unexected errors. Like resolver problems, user not found and similiar
 problems.
 

Either I don't understand the usage scenario you are talking about, or I
misunderstand what is being proposed in this thread, or you
misunderstand what is being proposed in this thread.  Here is a more
concrete example of a situation based on what I think is being proposed:

The Debian maintainer for a specific VPN decides it does not need
special shutdown handling, so he marks it to not require calling
/etc/init.d/SuperVPN stop when doing a shutdown or reboot.  This is
what I understand this thread is about.  This will result in SuperVPN
not being stopped until the final kill all remaining processes step of
the halt or reboot (i.e. don't waste time shutting this daemon down
cleanly, let it die abruptly just before halting).

Now, some other unrelated app, possibly a Debian-provided package and
possibly one installed manually by the sysadmin, uses this VPN and needs
it to be running during the app's normal shutdown (done using the
traditional /etc/init.d/* script) to avoid data loss.  The sysadmin or
Debian maintainer will know that a clean shutdown is required, so will
not mark this init script as skippable during the normal shutdown
sequence.

When the system shuts down, since this other app is not explicitly
marked as safe to kill without init script during system shutdown, its
init script gets called as usual during shutdown.  At this point, the
VPN is still up, because the kill all processes only happens _after_
all init scripts have been called for running daemons.

What is the problem you think might occur with the proposal from this
thread?

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: QUESTION: Debian Policy: Manual pages

[Marvin Renich]

* Ian Jackson [EMAIL PROTECTED] [080224 09:18]:
 Bas Zoetekouw writes (Re: QUESTION: Debian Policy: Manual pages):
  Why a recommends?  In order to satisfy the spirit of policy (every
  binary must have a man page) it would need to be a depends, imo.
 
 I think the point of policy is to ensure the manpage exists, not to
 require that it be installed.
 
 I think Suggests is the right dependency.  There is nothing wrong with
 installing a package without its documentation.
 
 Ian.
 

IANADD, but as a user, I disagree.  Policy [12.1] states:

  Each program, utility, and function should have an associated manual
  page included in the same package.

There is a big difference between a man page and more complete
documentation like a User Manual.

I _expect_ a man page for every executable.  A Depends, in my mind,
clearly satisfies the policy requirement, as the man page will be
available unless I use dpkg --force-* or some other drastic measure to
override the depends.  A Recommends may satisfy this (especially now
that apt defaults to installing them), but not quite as clearly.

Harshula, from your description it is not clear if c.tar.gz contains
substantial documentation beyond man pages.  If c.tar.gz contains very
little besides man pages and basic documentation, then Depend on c.deb,
and leave the man pages there.  If the tarball contains a lot of other
documentation, my preference as a user would be to have the man pages
moved into the binary a.deb and b.deb packages, and Recommend or Suggest
c.deb (without the man pages).

If you are making one source package with three binary packages, moving
the man pages to a different binary package is trivial.  If you are
making three separate source packages, I would still prefer to have the
man pages copied to the packages with their corresponding executable,
with a note in the README.Debian identifying the originating tarball.

I know this is more work (in the separate source package case), but as a
user I would appreciate not having to keep around a large documentation
package just to get man pages.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ${shlibs:Depends} results libfamin0 or libfam0?

[Marvin Renich]

* Andrew Lee [EMAIL PROTECTED] [080129 06:09]:
 Dear folks,
 
 I am working on pcmanfm package. It has build-depends on 'libgamin-dev',
 but somehow the binaries packages depends on 'libfam0'.
 
 I checked 'libgamin-dev' depends on 'libgamin0', but I don't know why
 the binaries packages are not depend on 'libgamin0'?
 
 Both libfam0 and libgamin0 package provides libfam0, so libfam0 might be
 correct dependency,
 
 But upstream author is not recommended to use libfam0 with this package,
 does anyone know what do to with this situation?
 
 And I also found and libgamin0 package contains:
 /usr/lib/libfam.so.0.0.0
 /usr/lib/libgamin-1.so.0.1.9
 /usr/lib/libfam.so.0
 /usr/lib/libgamin-1.so.0
 
 Not sure if this confused ${shlibs:Depends}?
 
 PS. Also cc this to libgamin0 and libfam0 maintainers.
 
 -Andrew
 

As libgamin0 Conflicts, Replaces, and Provides libfam0, then unless
pcmanfm _requires_ some functionality that libgamin0 provides that
libfam0 does not, depending on libfam0 rather than libgamin0 looks
correct to me.

What is the reason upstream discourages using fam?  Is it just because
he thinks gamin is a better file monitoring package or is there a
stronger technical reason?  Does pcmanfm work with fam, but not quite as
well as with gamin?  If so, the the Depends: gamin should probably be
Depends: gamin | fam.

However, apachetop switched from Depends: gamin | fam to Depends:
gamin and doodled switched from Depends: fam to Depends: gamin.
Both of these packages are maintained by Daniel Baumann (cc'ed to bring
this thread to his attention, though I think he reads this list).

Daniel, what was the reasoning for these changes?  Also, most of the
dependencies on fam are Recommends or Suggests.  If a package depends on
libfam0, can't the Depends: gamin (or fam) be relaxed to a Recommends?

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: adding user to package-forreign group

[Marvin Renich]

* Micha Lenk [EMAIL PROTECTED] [071129 17:27]:
[snip]
 
 But prior to releasing the package I am seeking for feedback here,
 whether that really is a good idea. Is there anything that I missed? Is
 it okay to mess around with other package's group memberships? Any other
 comments?
 
 Please give me feedback about whether to proceed this way or not.
 
 Regards
   Micha
 

This is somewhat of a hack, but since we are talking about a user
chipcard and a group cyberjack, can you have udev assign ownership
to chipcard:cyberjack?  I believe udev can handle separate files in
/etc/udev/rules.d/ so that the libchipcard package can have its own file
that adds chipcard as the owner without changing the group assigned by a
previous udev rule.  This would allow anyone who follows directions
found on the internet to still have it work, but for libchipcard to be
able to function without possibly interfering with an existing user
cyberjack that is unrelated to this smart card reader.  (I agree with
another post in this thread about not adding chipcard to the cyberjack
group unless you are sure that the cyberjack group is only used for the
purpose you think it is.)

Martin, does the udev rule for the Cyberjack specify root as owner, or
does it only specify the group?  I've only done simple things with udev,
so I'm not sure how two rules specifying conflicting owners would work.

Micha, if there is more to the cyberjack software than just a kernel
module and udev rule, and if you had the inclination, you could package
cyberjack as a separate Debian package, and then you would have control
of how the udev rules were set up for both packages.  Debian users who
install an official Debian cyberjack package (from main or non-free)
will, in general, expect the debian package to get it right and will
not be messing around with instructions found on the web.  Proper
instructions in README.Debian in both packages should clarify any
ambiguities.

My opinion is that the Debian package should make things work for
Debian, even when deviating from published instructions for non-Debian
users.  This gets trickier, as you are experiencing, when a Debian
package has to interact with non-Debian software, but if you package
cyberjack for Debian, that minimizes the impact on upstream support, as
most naive Debian users will contact Debian first, and the less naive
will read README.Debian.

disclaimer
I've never used libchipcard or a Cyberjack reader, nor have I looked at
the instructions for installing or using either.
/disclaimer

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: What to do when the LaTeX sources are missing, but an XML equivalent was rewritten from scratch ?

[Marvin Renich]

* Norbert Preining [EMAIL PROTECTED] [071119 17:28]:
[liberally snipped]
 
 And it matters to me that people can get optimal typographic quality.
 
 So either we have to distribute crippled versions of many documents,
 crippled only in the sense that yes, all the information/text is there,
 but the layout and design is crippled. Or we do not distribute them at
 all.
 
 Do the DFSG apply to design???
 
 What does it mean that a design is free?
 
 In both cases the user has the FULL RIGHT over the source code, can use
 it in any way he likes. Reuse it, alter it, etc etc. But in the second
 case he ALSO (!) has the right to have a nice beautiful well
 designed document.
 
 So do we TAKE rights from the users or GIVE them rights?
 
 Answers please?
 
 Best wishes
 
 Norbert
 

IANADD, but I am a Debian user, so let me provide an analogy that might
help clarify this.

If a software author designs a game, and this game is entirely his own
work (with a DFSG compatible license) except for one image file, which
has a freely distributable but only without modifications license.
This game would have to be distributed in non-free (not even contrib
would suffice).

We are assuming here that the one image file provides substantial
aesthetic appeal and the author believes the game to be best viewed
when this image is included.

But the game otherwise has a DFSG compatible license, so the Debian
packager replaces the image with one that is DFSG-free.  This game would
definitely be suitable for main.

There are, however, several ways that the Debian maintainer could help
the user get the free-beer image into the game.  For one, he could
provide a script that would download the file from the internet.
Another solution would be to provide a separate package in non-free that
contained the image, and have the game Suggest: the non-free image
package (and, of course, automatically use the image if the non-free
package is installed).

So Charles (the OP) could include his XML-based docs in the package in
main, and create a separate package in non-free for the original docs
(provided that Debian can distribute them) if he thinks the difference
in aesthetic quality is worth the effort.

Let me also address your question about taking away rights vs. giving
rights.  Debian does not promise to give its users all rights.  Debian
does not even strive to provide its users with all software that is
freely distributable.  It provides as much DFSG-free software as its
developers are willing and able to package.  Not distributing something
that is not DFSG-free is not taking away rights, it is merely saying
that the user must exercise his own right to download it himself.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: using testing/stable/unstable names with cdebootstrap

[Marvin Renich]

* Goswin von Brederlow [EMAIL PROTECTED] [071008 05:46]:
 Ritesh Raj Sarraf [EMAIL PROTECTED] writes:
 
  Hi,
 
  Is there a reason to not use stable/testing/unstable as the names in 
  config/suites file ?
 
  Currently it only has code names like etch/lenny/sid.
 
  Ritesh
 
 Does it matter anywhere? You can use testing as suite name on
 invocation and it will see that testing currently is lenny and use
 that.
 
 MfG
 Goswin
 

This is a slightly different issue than the OP was asking about, but
last time I tried (which was not recently), apt.conf
APT::Default-Release only accepted stable/testing/unstable, not the code
names.  This is a problem, since a new release will automatically
attempt to upgrade everything without warning the next time you use
aptitude (for common scenarios, such as Default-Release stable, both
stable and testing in sources.list).

I would like to set Default-Release to etch or lenny and then
manually change it when I am ready to upgrade after the release.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: kydpdict relationships

[Marvin Renich]

* Manoj Srivastava [EMAIL PROTECTED] [070724 21:05]:
 If we are going to transition to installing Recommends by
  default in lenny, I would say go with the Recommends, since it caters
  to more users.
 
 Or else, use Depends, but that makes the system less efficient
  for those of our users who decide they want a partially  proprietary
  solution (which we promise to support as well, as I recall).
 
  But we dont care about those non-free files, as they wont ever end up
  in a thing where you could add some relation in your package control
  data.
 
 Sure, but the proprietary .deb could use Enhances :). If ever
  the packaging system frontends decide to support that, it could still
  be useful.
 
 manoj

Why not

Depends: free-dictionary | any-dictionary

and have all (free and non-free) dictionaries Provides: any-dictionary?

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Marvin Renich]

* Josselin Mouette [EMAIL PROTECTED] [070725 06:10]:
 Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit :
  The latter might be fine as a local policy; but surely is not
   correct as a Debian default.  We should make it _possible_ to implement
   a local policy of hiding information from users; but we must not let
   information hiding be the default; nor the only possible local policy.

Exactly.

 
 No. We should hide part of the information by default, but make it both
 possible:
   * for users to access the extra information without anything too
 complicated;
   * for administrators to really lock information if that's really
 useful.
 
 Relevant information easily gets lost when there is too much of it,
 which is why a *default* setup should never show all available
 information. And this isn't only relevant for menus.
 

Absolutely *wrong*.

Gnome and KDE are targeted primarily at desktop users, not servers.  If,
as a desktop user, I install a graphical app on my machine, I *expect*
to see that app in the main menu.  The place where I put important
and/or frequently used apps is on a panel/toolbar.

If a novice user installs an app and then goes to the menu and doesn't
find it, how is this user supposed to know what to do?  This is
completely *un*usable.  The more novice the user, the more important it
is for the *default* to be for all graphical apps to be shown.  Then let
the individual user decide which ones are important to him/her.

Menus, by their nature, are inherently unusable for the most frequently
used apps, and we should not be trying to make them more usable at the
expense of making less frequently used apps harder to access.

Menus make less frequently used apps easy to get at, while toolbars make
frequently used apps even easier; use the right tool for the right job.

If Gnome were to have a menu policy configuration, with the Debian
default being show all apps, but which made it easy for the less is
more useable camp to accept someone else's idea of most important
apps with a single setting rather than having to wade through the menu
editor, I would find that an excellent compromise.

As for multiuser systems and servers, the same logic applies.  The
Debian default should be to show all apps, then let the sysadmin tailor
that for the installation, then let the users fine tune it.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Marvin Renich]

* Josselin Mouette [EMAIL PROTECTED] [070725 12:57]:
 Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit :
  Gnome and KDE are targeted primarily at desktop users, not servers.  If,
  as a desktop user, I install a graphical app on my machine, I *expect*
  to see that app in the main menu.  The place where I put important
  and/or frequently used apps is on a panel/toolbar.
 
 Do you expect to see console applications in the menu as well? All
 interpreters and shells? Window managers?

My original message was specifically concerned with graphical apps.  I'm
not sure which console apps should be displayed; for the most part, I
think the Debian maintainer should decide whether it deserves to be
displayed by default.

Window managers *definitely* should be displayed.  If I went to the
trouble of installing sawfish in addition to metacity, I would like to
be able to use both.  Yes, from the menu.

  If a novice user installs an app and then goes to the menu and doesn't
  find it, how is this user supposed to know what to do?
 
 This bit is correct: someone installing an app can reasonably expect to
 see it in the menu. However you are drawing wrong conclusions:
 
This is
  completely *un*usable.  The more novice the user, the more important it
  is for the *default* to be for all graphical apps to be shown.  Then let
  the individual user decide which ones are important to him/her.
 
 If the users installs the distribution with default settings or starts a
 session on a multi-user setup, he should find a usable menu, not a menu
 with all possible applications he never wanted to install.

Usable, yes; minimal, no.  See the next paragraph:

  Menus, by their nature, are inherently unusable for the most frequently
  used apps, and we should not be trying to make them more usable at the
  expense of making less frequently used apps harder to access.
 
 Why shouldn't we attempt to make menus usable?

I didn't say we should not make them usable, I said we should not try to
make them more usable *by reducing access to less frequently used apps*.

  Menus make less frequently used apps easy to get at, while toolbars make
  frequently used apps even easier; use the right tool for the right job.
 
 Guess what, toolbars are not used by a good share of users. Toolbars
 sound obvious for experienced users, but a novice will never have the
 idea to modify the interface that is shown to him; which is why this
 interface must be as straightforward as possible - and that also
 includes good default shortcuts in the toolbar.

That a novice will not know that he can change the interface is even
more reason to make sure the (graphical) app that he installed is in the
menu.  A good system of hints that includes one about putting
applications on the toolbar would be very helpful.

Also, my experience is that a good share of less-technically-oriented-
but-comfortable-using-a-computer users actually do use toolbars.

Josselin, we have not met face-to-face, and email does not convey
emotion very well, so I want to make sure you know that this is not a
personal attack.  Your contribution to Debian is significant, and I
appreciate it (along with that of the many other DD's).  I respect the
technical opinions that you have expressed on the debian mailing lists,
and agree with many of them.  But I strongly disagree with you on this
issue.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Marvin Renich]

* Frank Küster [EMAIL PROTECTED] [070725 10:08]:
 Mike Hommey [EMAIL PROTECTED] wrote:
 
  On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster [EMAIL PROTECTED] 
  wrote:
  Mike Hommey [EMAIL PROTECTED] wrote:
  
   On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL 
   PROTECTED] wrote:
   Absolutely *wrong*.
   
   Gnome and KDE are targeted primarily at desktop users, not servers.  If,
   as a desktop user, I install a graphical app on my machine, I *expect*
   to see that app in the main menu.  The place where I put important
   and/or frequently used apps is on a panel/toolbar.
  
   If you install the python interpreter on your machine, do you also 
   expect it
   to appear in the main menu ?
  
  No, why do you ask?  The python interpreter isn't a graphical
  application.  It also doesn't have a menu entry, so there's nothing to
  hide. 
 
  You obviously never looked at the Debian menu.
 
 How do you come to that conclusion?  On the contrary, I use it
 frequently (there's other menu in my WM).  
 
 But from Marvin's sentence (which I think is right) 
 
 ,
 | If, as a desktop user, I install a graphical app on my machine, I
 | *expect* to see that app in the main menu
 `
 
 you cannot conclude on his (or my) expectations regarding python, because
 python is not a graphical application.
 

Thanks Frank; that is exactly what I meant.

...Marvin

PS  Please do not CC me when replying to the list, I am subscribed.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Proposed new POSIX sh policy, version two

[Marvin Renich]

* Jari Aalto [EMAIL PROTECTED] [061123 06:56]:
 
 But for the shells there are. I think the Policy should exempt shells
 and require that if package is not POSIX/Susv -compiant, it needs to
 announce dependance on a particular shell -- where it bash, tcsh,
 pdksh ..., if it uses those shells special features.
 
 Jari
 

Making an exception like this is not a good idea, and is not necessary.
If it is decided that allowing bash to be replaced by one of a short
list of other shells is a good idea, then make each shell in the list
Provide: almost-posix-shell (or something) and make almost-posix-shell
essential (can a virtual package be essential?).  Or make a real package
almost-posix-shell that depends on bash | dash | 

I have no particular opinion on the bash/dash/* issue, but making policy
conflict with itself or have unnecessary special cases is bad.

In fact, you could remove the whole issue of listing specific features
required of /bin/sh from the policy if you make a real package
almost-posix-shell, place the documentation of what can be expected of
it in the package, and replace bash by almost-posix-shell in the
essential list.

This doesn't, of course, do anything to help the issue of ensuring the
non-bugginess (w.r.t. requirements of almost-posix-shell) of the shells
that almost-posix-shell depends on, but it simplifies policy and moves
the details into a single location.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ITP: subtitleeditor -- Graphical subtitle editor with sound waves representation

[Marvin Renich]

* Peter Samuelson [EMAIL PROTECTED] [060812 14:00]:
 
 No need to mention the competitors, really.

I strongly disagree.  While an individual upstream author may have
competitive feelings towards other software that provides similar
functionality, one of Debian's primary priorities is its users (as
opposed to its upstream authors).  The Debian community recognizes that
different software that provide the same basic functionality may each
have their own advantages and disadvantages, and providing more than one
package with similar functionality is usually a Good Thing.

If you are going to provide two subtitle editors (for example), knowing
the pros and cons of each helps the users (me, for one!) decide which
one (or more) best suits my needs.  Listing specific (important)
differences from other specifically named packages in the package
description is extremely helpful to me (and, presumably, other users).

Also, it impresses me when a package description says something like if
you need feature X, you are better off with package M, but this package
provides feature Y which package M doesn't have.

...Marvin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: texlive-basic_2005-1_i386.changes REJECTED

[Marvin Renich]

* Norbert Preining [EMAIL PROTECTED] [051128 11:20]:
 Dear all!
 
 Please comment, not only on the package naming, but also on the
 bin-to-source mapping.
 
 
 texlive-documentation-source  57M
 
 Reasoning: The documenatation is actually in a specific language, so we use
 the respective language code.
 texlive-documentation-basetexlive-base-doc
 texlive-documentation-bulgarian texlive-bg-doc
 texlive-documentation-czechslovak texlive-cs-doc
 texlive-documentation-dutch   texlive-nl-doc
 texlive-documentation-english texlive-en-doc
 
 
 Best wishes
 
 Norbert
 

In [1], Thiemo Seufer asserts that FWIW, Debian package names prefer
e.g. foo-en-uk-doc over foo-documentation-ukenglish.  I completely
disagree.

There is already precedent for using foo-doc-fr ordering of -doc-LANG:
aptitude-doc-XX, udo-doc-XX, mdnkit-doc-XX, otrs-doc-XX,
speechd-el-doc-cs (the -el- is emacs lisp, -cs is Czech),
speech-dispatcher-doc-cs, lifelines-doc-sv, samba-doc-ja.

I saw no examples of -XX-doc with XX a language.

The most notable exceptions to PKG-doc-XX were doc-linux-XX and
doc-debian-XX, but in these cases, you can consider 'doc-linux' and
'doc-debian' to be the package names, rather than documentation for the
linux or debian package.  And, the -XX still came after.

I think -doc-XX is more natural, and I don't see why in [2] Thiemo said
that it made pattern matching harder.  In fact, I think it is easier to
find documentation for the foo package with foo-doc; then you can easily
see what languages are available.  Suppose you speak German and are
looking for documentation for package foo.  You search for foo-doc; it
lists several, but not foo-doc-de.  However, it lists foo-doc-fr, and
you speak French as a second language.  Weeding out foo-docutils with
the -doc-XX ordering is at least as easy as finding doc packages in all
languages with Thiemo's ordering.

I am not currently a texlive user, but as a Debian user, I would much
prefer the current precedent rather than your proposed -XX-doc.

...Marvin

[1] http://lists.debian.org/debian-devel/2005/11/msg01661.html
[2] http://lists.debian.org/debian-devel/2005/11/msg01673.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]