Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO  Pendant le  journal  télévisé du  jeudi  10 mai  2012, vers  20:29,
Jean-Christophe Dubacq  disait :

> I do not know about trivially merging changes in the etc-overrides-lib
> model, but in the current model, I am presented with the dpkg prompt
> about conffiles for some programs where I added (or changed) only one
> line (off the top of my head: only the servers list in roundcube, for
> example), and dpkg does not propose to merge the two files: I am either
> stuck with keeping my old file, taking the new, or using a shell. All
> these things are interactive and prevent unattended upgrades without
> disruption of services.

roundcube uses  ucf for its  main configuration file and  therefore, you
should have a prompt with possibility to merge.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk(KERN_WARNING "%s: Short circuit detected on the lobe\n",
dev->name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c


pgputTalXJ2N9.pgp
Description: PGP signature

Re: RFC: OpenRC as Init System for Debian

[Tollef Fog Heen]

]] Uoti Urpala 

Hi,

> Wrong: as mentioned in this thread before, one of the advantages of the
> etc-overrides-lib model is the option of having a file in /etc that
> first includes the one in /lib, then overrides just one particular
> value. This allows handling more updates without needing manual changes,
> as you can automatically pick up other updated values while keeping the
> override, without needing to do 3-way merges.

This doesn't always work, though.  For instance, for systemd, you'd have
no way to get rid of an ExecStartPre line, since you can have multiple
of them.  It's probably not that common, but it's a use case I want to
support.

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


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

Re: mass bug filing: debcheckout fails

[jaalto]

On 2012-04-24 18:22, Ansgar Burchardt wrote:
|
| I noticed you started to file bugs for non-working debcheckouts.  Was
| this discussed anywhere as suggested by the developer's reference[1]?

Hi Ansgar,

There are only handful of packages that mistakenly have their Vcs-*
headers set up incorrectly so a minor bug reports and corrective
instructions were sent. In this regard I dind't consider it worthy of
"mass bug filing" process although it may have been in place.

| imagine a new lintian check could also achieve.

Correct. The problem is that Lintian's returned severity level does
not adequately correspond to the problem level this error is
causing. Many package maintainers don't even see the Lintian warnings
if they don't crank up the reporting levels. I've asked Lintian
maintainer to reconsider the severity of the Vcs header check.

This particular case directly affects usability because every
debcheckout command fails for all non-members that don't have
development access to Vcs repositories.

A minor bug report serves as a reminder to make maintainers aware of
the problem and to consider including a fix in future uploads.

Jari

| [1] 



-- 
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/20120511055436.gi13...@taiko.cante.net

Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

[Gergely Nagy]

Don Armstrong  writes:

> On Thu, 10 May 2012, Gergely Nagy wrote:
>> FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
>> do something *very* close to what etc-overrides-non-etc does. To the
>> point that changing a file under /etc/default, or adding a snippet
>> to conf.d/ can break just as well when the underlying default
>> changes as if that upstream happened to be outside of /etc.
>
> That's true. I suspect that much of conf.d/* and default/* are a
> consequence of the lack of easy 3-way merge support in dpkg. But
> that's kind of an orthogonal issue.

I don't think that is so. It's also there to allow other packages to
drop snippets there. Modifying another package's conffile would be
against the policy, so conf.d/-style snippets are the obvious solution.

Nothing to do with the lack of merge in this case. Even if dpkg gains
fabulous merge support that never fails, ever, conf.d/ will still be
used because we need the ability to add snippets from unrelated
packages.

>> Except it's easier to follow, since the default is never modified
>> by the admin, while if it's in /etc too, like in plenty of cases in
>> the archive, both can change, and we end up with even scarier
>> situations that can't be resolved sanely.
>
> I'm unable to follow. In the etc-overrides-non-etc case, we would be
> increasing the number of cases where we had copies in /etc and in
> non-etc.
>
> If things were just in /etc, they wouldn't be in non-etc, and you'd
> only have one copy in all cases.

True, if the non-etc stuff were simply copied, we'd have a single
copy. With all the disadvantages that brings, like not being able to
override the default from another package, as that would mean we have to
modify a configuration file.

In the case of systemd, you need to be able to override the default from
another, unrelated package. At least for things like the syslog
service.

At the moment, systemd has /lib/systemd/system/syslog.service, which
starts the journal. If I want to override that, I need to override the
syslog.service, which is done by placing a file in
/etc/systemd/system/syslog.service (whether a symlink, or a file,
doesn't matter; the syslog daemons in debian place a symlink).

If we didn't have etc-overrides-lib, how would you do this? How would
you make it able to override a single service, from another package?
Play dpkg-divert tricks? Or use conf.d/-style stuff?

The latter suffers from the same issue etc-overrides-non-etc suffers
from, the former makes it much harder for admins to override services,
and I don't like the idea of dpkg-divert'ing config files all over the
place either..

-- 
|8]


-- 
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/873977s1lq@luthien.mhp

Re: upstream shared library major versions

[Brian May]

Hello,

Can somebody here please check out my response to the claim ""ld"
prefers linking with the oldest [library version]."

I suspect upgrading the major version to major * 1000 may have only
worked due to unrelated reasons.

Thanks
-- 
Brian May 


-- 
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/CAA0ZO6Cz0TZ=RS=z2ywt+cncermqvtmyqij1+fv7k7bve9c...@mail.gmail.com

Re: RFC: OpenRC as Init System for Debian

[Ben Hutchings]

On Thu, May 10, 2012 at 09:56:57PM +0100, Ben Hutchings wrote:
> On Thu, May 10, 2012 at 10:55:06AM -0700, Don Armstrong wrote:
> > On Thu, 10 May 2012, Uoti Urpala wrote:
> > > You're pretty much just saying that dpkg and helpers like ucf have
> > > implemented better functionality than rpm. I don't see how that's
> > > relevant to the discussion.
> > 
> > The reason why it is relevant is because in the etc-overrides-lib
> > model you are unable to trivially merge local changes with upstream or
> > packaging changes unless you add additional logic in the postinst to
> > handle etc-overrides-lib. Having configuration files in /etc and using
> > ucf or similar enables you to deal with this problem easily.
>  
> In the etc-overrides-lib model, program defaults and local
> configuration are effectively being merged every time the program
> starts.
[...]

Apparently I was mistaken and that's not what's usually implemented.
So this really does look like a workaround for stupid package
managers.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120511010208.gg4...@decadent.org.uk

Work-needing packages report for May 11, 2012

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 394 (new: 2)
Total number of packages offered up for adoption: 169 (new: 2)
Total number of packages requested help for: 60 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   audacious-analog-vumeter-plugin (#671890), orphaned 3 days ago
 Description: VU meter plugin for xmms and audacious
 Installations reported by Popcon: 229

   dumpasn1 (#672300), orphaned yesterday
 Installations reported by Popcon: 71

392 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   cmph (#671455), offered 6 days ago
 Description: C Minimal Perfect Hashing Library
 Installations reported by Popcon: 29

   tetzle (#671754), offered 4 days ago
 Description: Jigsaw puzzle game
 Installations reported by Popcon: 86

167 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] spice (#671627), requested 5 days ago
 Description: Simple Protocol for Independent Computing Environment
 Installations reported by Popcon: 3650

   apt-xapian-index (#567955), requested 829 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 55768

   asymptote (#517342), requested 1168 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3269

   athcool (#278442), requested 2753 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 95

   balsa (#642906), requested 228 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 256

   bastille (#592137), requested 642 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 230

   boinc (#511243), requested 1218 days ago
 Description: BOINC distributed computing
 Installations reported by Popcon: 1831

   cardstories (#624100), requested 381 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 7

   chromium-browser (#583826), requested 711 days ago
 Description: Chromium browser
 Installations reported by Popcon: 10644

   cryptsetup (#600777), requested 568 days ago
 Description: configures encrypted block devices
 Installations reported by Popcon: 7874

   debtags (#567954), requested 829 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2531

   doc-central (#566364), requested 838 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 213

   elvis (#432298), requested 1767 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Installations reported by Popcon: 370

   fbcat (#565156), requested 848 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 160

   flightgear (#487388), requested 1419 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 851

   freeipmi (#628062), requested 350 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 1299

   gnat-4.4 (#539633), requested 1486 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 1686

   gnat-gps (#496905), requested 1351 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 441

   gnupg (#660685), requested 80 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 124065

   golang (#668870), requested 25 days ago
 Installations reported by Popcon: 203

   grub2 (#248397), requested 2922 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 114071

   hfsprogs (#557892), requested 897 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1163

   hotkey-setup (#483107), requested 1444 days ago
 Description: auto-configures laptop hotkeys
 Installations reported by Popcon: 3956

   irssi-scripts (#663577), requested 59 days ago
 Description: collection of scripts for irssi
 Installations reported 

Re: RFC: OpenRC as Init System for Debian

[Nikolaus Rath]

m...@linux.it (Marco d'Itri) writes:
> On May 10, Bjørn Mork  wrote:
>
>> Agree.  Copying a large set of default policies into /etc just because
>> they *can* be overridden is not user friendly.  And it does not make the
>> defaults any more configuration either. It just hides important local
>> changes and makes it difficult both for the user and the application
>> itself to distinguish between defaults and configuration overrides.
>
> Wrong: since you have to copy the whole file to override it, and files 
> in /lib have no conffiles handling, after an upgrade you will not know 
> what was changed by you and what was changed upstream.

I think everyone here agrees with that. The interesting case is when
files in /etc/ can either explicitly include the /lib file, or
implicitly override the /lib settings.

It's not clear to me why such a system would be inferior to the current
debian practice.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/87ipg3ioga@vostro.rath.org

Re: RFC: OpenRC as Init System for Debian

[George Danchev]

On Friday 11 May 2012 00:01:14 Uoti Urpala wrote:
--cut--
> > You need to at least start reading some man-pages (a good start would be
> > ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming
> > suggestion like "improvements to be able to alert the user about
> > changes". This is already there, and has been there for a long time, as
> > also mentioned before.
> 
> I was talking about the etc-overrides-lib case; did you misunderstand
> that? Do those tools already have functionality which could be used for
> that case as is? If they do, I don't think it has been mentioned.

You can even do without any special tools for the applications following etc-
overrides-lib case, since at the end it all boils down to shipping the new 
default configuration file in /lib, and warn them about potential updates. 
There 
shouldn't be any merges involved, since this is the whole point of directory 
separation.

Postinst's 'configure' stage:

* communicate a stock (default) configuration file in /lib
diff /usr/share/doc/foo/foo.conf   /lib/foo.conf (or cksum them)
warn the user if the default (stock) configuration file has changed, send mail.
cp  /usr/share/doc/foo/foo.conf /lib/foo.conf

* optionally handle locally modified /etc/foo.conf... we should leave it alone,
and not mess up with it, since this is a local admin setttings overriding 
/lib/foo.conf as a whole or including it and overriding certain values only, 
but anyway a simple call to ucf for completeness:
ucf /usr/share/doc/foo/foo.conf  /etc/foo.conf
ucfr foo /etc/foo.conf

likewise, postrm, as shown in the man page.

Applications using more than one configuration file of effectively the *same 
type 
and purpose* (since there applications with several configuration files, 
grouped 
on different purposes) on startup would also cause the very same burden to the 
admin mentally exesicing this very same process and guessing which was set 
where and what overrides what. Not entirely pretty.

-- 
pub 4096R/0E4BD0AB 


-- 
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/201205110212.30503.danc...@spnet.net

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Don Armstrong wrote:
> On Thu, 10 May 2012, Ben Hutchings wrote:
> > In the etc-overrides-lib model, program defaults and local
> > configuration are effectively being merged every time the program
> > starts.

This seems to assume that the program would always read both. systemd
unit files don't work this way; rather, if the file exists in /etc, then
only that version is read. However, you can use ".include" in the file
to read the default version and then override only parts. So you can
choose which semantics you want for each file you modify.


> This is only the case if the configuration files are fine grained
> enough that overrides to a configuration file wouldn't also need to
> incorporate upstream/packaging changes. In such a case,
> etc-overrides-non-etc makes perfect sense, and you wouldn't normally
> distribute a configuration file at all (or if you did, it'd just
> contain commented, current default values for commonly altered
> values).

I don't see why you'd equate it being reasonable to override just a few
values and there being no need for a distro configuration file at all.
Why would it be rare for a program to need distro configuration but have
some things the user would want to override independently?

> In cases where the configuration files are not (or co-mingled with
> application logic), then etc-overrides-lib is the same as running dpkg
> with --force-conf-old and having the configuration files in /etc.

That's assuming you don't improve the tools; etc-overrides-lib does not
intrinsically imply that. And of course you'd still have the other
advantages which would not be "the same".



-- 
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/1336689772.2227.158.camel@glyph.nonexistent.invalid

Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

[Don Armstrong]

On Thu, 10 May 2012, Gergely Nagy wrote:
> FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
> do something *very* close to what etc-overrides-non-etc does. To the
> point that changing a file under /etc/default, or adding a snippet
> to conf.d/ can break just as well when the underlying default
> changes as if that upstream happened to be outside of /etc.

That's true. I suspect that much of conf.d/* and default/* are a
consequence of the lack of easy 3-way merge support in dpkg. But
that's kind of an orthogonal issue.

> Except it's easier to follow, since the default is never modified
> by the admin, while if it's in /etc too, like in plenty of cases in
> the archive, both can change, and we end up with even scarier
> situations that can't be resolved sanely.

I'm unable to follow. In the etc-overrides-non-etc case, we would be
increasing the number of cases where we had copies in /etc and in
non-etc.

If things were just in /etc, they wouldn't be in non-etc, and you'd
only have one copy in all cases.


Don Armstrong

-- 
a friend will help you move
a best friend will help you move bodies
but if you have to move your best friend's body
you're on your own
 -- a softer world #242
http://www.asofterworld.com/index.php?id=242

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120510220412.gg3...@rzlab.ucr.edu

Re: Directory /boot/console-setup

[Steve Langasek]

On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote:
> First the problem in few words.  The package console-setup needs an 
> access to a directory similar to /var very early during the boot process 
> - when /var is not yet mounted.  Currently it creates files in the 
> directory /etc/console-setup.  As a result when the package is purged it 
> is impossible to tell which files in /etc/console-setup are 
> automatically generated (so they have to be removed) and which are put 
> there by the admin (so we are not permitted to remove them).

I think your premise here is false.  The /etc/console-setup directory is
owned by the console-setup package; there are certain predictable filenames
that will have been created by the package; and any files in this directory
are configuration files for console-setup, whether created by the admin
manually or created by the package.

So it's perfectly permissible under policy for the package to remove these
files on purge.

> One possible solution is to generate the files in a directory named 
> /etc/console-setup/.cache and to put a file /etc/console-setup/.cache/README
> explaining the purpose of this directory and warning the admin that the 
> package is free to remove or overwrite at any time any files in this 
> directory.

> Please don't complain that this is a policy violation. :) I think at the 
> moment there is no solution of the problem without policy violation and 
> the packages kbd, console-tools and console-setup have been happily 
> doing policy violations regarding /etc since the very first version of 
> Debian.

My complaint is that this is excessively ugly.  For persistent variable data
that needs to be available during early boot, even when this is binary data
that the user won't edit, /etc is the normal place to keep it - it's the
creation of a a .cache subdirectory that I object to.

> The second solution I propose is to generate the files in a directory 
> /boot/console-setup.  After all the whole need of such directory arises 
> due to the specifics of the boot process.

> Personally, I think I prefer /boot to /etc.

Not useful for reasons already discussed.
> 
> Some additional info: most of the time the package requires only 
> read-only access to this directory.  Write-access is required only in 
> the following occasions:

> 1. when the admin is dpkg-reconfiguring the package
> 2. during the first reboot (but not too early in the boot process) if 
> the admin has edited the configuration files of console-setup by hand 
> and he has not used the command "setupcon --save"
> 3. when the admin uses the command "setupcon --save"

Yep, which makes this entirely consistent with storage on the rootfs,
including when the rootfs is read-only by default, and /etc the right place
to put the data.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Don Armstrong]

On Thu, 10 May 2012, Ben Hutchings wrote:
> In the etc-overrides-lib model, program defaults and local
> configuration are effectively being merged every time the program
> starts.

This is only the case if the configuration files are fine grained
enough that overrides to a configuration file wouldn't also need to
incorporate upstream/packaging changes. In such a case,
etc-overrides-non-etc makes perfect sense, and you wouldn't normally
distribute a configuration file at all (or if you did, it'd just
contain commented, current default values for commonly altered
values).

In cases where the configuration files are not (or co-mingled with
application logic), then etc-overrides-lib is the same as running dpkg
with --force-conf-old and having the configuration files in /etc.

> Maybe users ought to be able to request notification when the
> defaults change. But isn't that true regardless of whether those
> defaults are written in the configuration file format or as part of
> the program itself?

Sure. I personally think it'd be nice to know if the defaults changed
too when I'd altered them. But doing that is difficult when the
defaults aren't already specified in a configuration file. Handling
configuration files as configuration files isn't that difficult.
 

Don Armstrong

-- 
Physics is like sex. Sure, it may give some practical results, but
that's not why we do it.
 -- Richard Feynman

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120510215207.gf3...@rzlab.ucr.edu

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On May 10, Jean-Christophe Dubacq  wrote:

> There are cases where file in /etc overrides only the directives present
> in /etc and not the rest. I prefer this way.
Fine, but they are not the cases which we are discussing.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#672160: Directory /boot/console-setup

[Yves-Alexis Perez]

On ven., 2012-05-11 at 00:16 +0300, Anton Zinoviev wrote:
> On Thu, May 10, 2012 at 09:40:23PM +0100, Ben Hutchings wrote:
> > 
> > Generally the console has to work even before root is mounted, so
> > that the user can enter a decryption password if necessary.
> 
> Unfortunately, as far as I know currently this doesn't work in 
> Debian.  Proper wishlist bug reports have been filled but we 
> haven't come yet to a solution that is good for all developers. 

What do you mean with “this doesn't work in Debian”? Some people do use
encrypted root and they do have a working console asking for the
passphrase.

Regards,
-- 
Yves-Alexis


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

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

George Danchev wrote:
> On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
> > I don't see how the following would make this comparison with rpm relevant.
> 
> It was a comparison of the packaging system facilities to handle upgrades of 
> the configuration files of the applications. This was initially started by 
> you 
> as a misguided comparison between etc-overrides-lib (apples) vs. dpkg 
> conffiles 
> (oranges). Basically you're mixing up packaging system facilities to handle

No, I didn't mix those up like that. I think you're referring to my
comment about Josh Triplett providing technical reasons to prefer using
etc-overrides-lib semantics, but Steve McIntyre's reply only mentioning
existing "set of tools" as a counterargument (which was silly given his
rpm comments). That was comparing the quality of their arguments, not
comparing etc-overrides-lib model vs dpkg functionality.

I didn't initially parse the "comparison" in your original post that
way, because it doesn't seem like a plausible way to read my original
post.


> > Yes, you do need some tool improvements to be able to alert the user
> > about changes. This has been mentioned before. I don't think this would
> 
> You need to at least start reading some man-pages (a good start would be 
> ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming suggestion 
> like "improvements to be able to alert the user about changes". This is 
> already there, and has been there for a long time, as also mentioned before.

I was talking about the etc-overrides-lib case; did you misunderstand
that? Do those tools already have functionality which could be used for
that case as is? If they do, I don't think it has been mentioned.


> > And as also mentioned before, the include option should reduce the
> > number of cases where you need to do 3-way merging.
> 
> You don't seem to understand that style of reading of configuration files of 
> the 
> applications is in the realm of the applications themselves and packaging 
> systems facilities which help handling upgrades of these application 
> configuration files can not frivolously add "include" or any other convenient 
> option directives you are suggesting to these application configuration files.

Of course I do understand that include directives require application
support. I don't know where you got the idea that such directives would
be added by any automatic packaging helper; this is about how user
modifies configuration (use include+override rather than copy+modify).



-- 
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/1336683674.2227.138.camel@glyph.nonexistent.invalid

Re: Bug#672160: Directory /boot/console-setup

[Anton Zinoviev]

On Thu, May 10, 2012 at 09:40:23PM +0100, Ben Hutchings wrote:
> 
> Generally the console has to work even before root is mounted, so
> that the user can enter a decryption password if necessary.

Unfortunately, as far as I know currently this doesn't work in 
Debian.  Proper wishlist bug reports have been filled but we 
haven't come yet to a solution that is good for all developers.

Anyway, we may not expect that all initrd images are able to 
configure the console.
 
> What is it that needs to be done before other filesystems are
> mounted, but not before root is mounted?

At least the keyboard has to be configured before fsck runs.

Anton Zinoviev


-- 
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/20120510211603.ga30...@debian.lan

Re: RFC: OpenRC as Init System for Debian

[gregor herrmann]

On Thu, 10 May 2012 20:29:05 +0200, Jean-Christophe Dubacq wrote:

> in the current model, I am presented with the dpkg prompt
> about conffiles for some programs where I added (or changed) only one
> line (off the top of my head: only the servers list in roundcube, for
> example), and dpkg does not propose to merge the two files: I am either
> stuck with keeping my old file, taking the new, or using a shell. 

Right, and I agree that's annoying.

Which means that our handling of conffiles has room for improvement,
and using Config::Model would be a way to do it.

Cheers,
gregor
 
-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Paul McCartney: Say Say Say


signature.asc
Description: Digital signature

Bug#672410: ITP: wherpygo -- player for wherigo cartridges

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: wherpygo
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : None, first publication will be in Debian.
* License : AGPL-3+
  Programming Lang: Python
  Description : player for wherigo cartridges

A sister-site of geocaching.com is wherigo.org. There people can publish 
cartridge files, which can contain tour guides, puzzles (often leading to a 
geocache), or other adventure-style games. The adventures always make use of a 
gps receiver to know your position, and part of the adventure is to actually 
walk around with your legs instead of your keys. A player is required to use 
those cartridges. The site provides a non-free player. There are several other 
players available for different phones.

Wherpygo is another player. It is designed for a netbook. That is not a usual 
platform for the game, because taking a netbook with you is not very 
comfortable. However, the good thing about it is that the interface has more 
features than the default interface. It also includes a debugging mode, which 
can be used by cartridge writers, or players who are stuck.



-- 
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/20120510205309.27735.42515.reportbug@localhost

Re: RFC: OpenRC as Init System for Debian

[Ben Hutchings]

On Thu, May 10, 2012 at 10:55:06AM -0700, Don Armstrong wrote:
> On Thu, 10 May 2012, Uoti Urpala wrote:
> > You're pretty much just saying that dpkg and helpers like ucf have
> > implemented better functionality than rpm. I don't see how that's
> > relevant to the discussion.
> 
> The reason why it is relevant is because in the etc-overrides-lib
> model you are unable to trivially merge local changes with upstream or
> packaging changes unless you add additional logic in the postinst to
> handle etc-overrides-lib. Having configuration files in /etc and using
> ucf or similar enables you to deal with this problem easily.
 
In the etc-overrides-lib model, program defaults and local
configuration are effectively being merged every time the program
starts.  I think that this is generally better than either the
dpkg-conffile model (ask the user to resolve) and the rpm-conffile
model (back up local version).

Maybe users ought to be able to request notification when the
defaults change.  But isn't that true regardless of whether those
defaults are written in the configuration file format or as part
of the program itself?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120510205657.gf4...@decadent.org.uk

Re: ITP: libzeromq-perl -- A ZeroMQ2 wrapper for Perl

[Julian Taylor]

On 05/10/2012 05:53 PM, Harlan Lieberman-Berg wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Harlan Lieberman-Berg" 
> 
> Package name:   libzeromq-perl
> Version:0.21
> Upstream Author:Daisuke Maki 
> URL:http://search.cpan.org/dist/ZeroMQ/
> License:GPL-1+ or Artistic
> Programming Lang:   Perl
> Description:A ZeroMQ2 wrapper for Perl
> 
> The ZeroMQ module is a wrapper of the 0MQ message passing library for Perl.
> It is a thin wrapper around the C API.
> 
> ZeroMQ is an intelligence socket library that acts like a concurrency
> framework.  It is faster than TCP for clustered products and supercomputing,
> carrying messages across inproc, IPC, TCP and multicast.  It can connect
> N-N via fanout, pubsub, pipeline, request-reply, and several other models.
> 
> 

libzeromq-perl is already packaged:
http://packages.qa.debian.org/libz/libzeromq-perl.html



signature.asc
Description: OpenPGP digital signature

Re: Bug#672160: Directory /boot/console-setup

[Ben Hutchings]

On Thu, May 10, 2012 at 10:13:39PM +0300, Anton Zinoviev wrote:
> On Thu, May 10, 2012 at 07:45:21PM +0200, Sven Joachim wrote:
> > 
> > Maybe I'm missing something obvious, but /boot seems to be a very bad
> > choice for the location, simply because it is not available any earlier
> > than /var.
> 
> Ah, you are right.
> 
> So it seems only /etc is an option. Thanks.

Generally the console has to work even before root is mounted, so
that the user can enter a decryption password if necessary.

What is it that needs to be done before other filesystems are
mounted, but not before root is mounted?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120510204023.ge4...@decadent.org.uk

Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC asInit System for Debian]

[Uoti Urpala]

Don Armstrong wrote:
> On Thu, 10 May 2012, Uoti Urpala wrote:
> > I don't see how the following would make this comparison with rpm
> > relevant.
> 
> This is debian-devel, and we're talking about configuration file
> handling in Debian, which makes ucf and dpkg relevant.

Yes, ucf and dpkg are relevant to the discussion. However, that doesn't
mean every remark about them would be.


> > Yes, you do need some tool improvements to be able to alert the user
> > about changes.
> 
> Right. So for every package which does this, you have to check to see
> whether a configuration file in /etc has had it's corresponding
> non-etc configuration file changed, and then offer to merge them
> together.

dpkg does not currently offer merge functionality, so if you implement
that you're actually improving over what dpkg can do now. And I believe
supporting this should be a reasonably simple extension to ucf.

> Thus, when you fully implement etc-overrides-non-etc, you have to
> handle configuration files in non-etc *exactly* as if they were in etc
> to start with. [Lets not even start with trying to figure out how you
> would handle deleting a non-etc configuration file when there's a
> difference between a non-existent file and an empty one.]

If the application requires the deletion of a file under /lib to achieve
particular configuration semantics, I think that's clearly a broken
application. I don't see how such brokenness would be any more relevant
with etc-overrides-lib than without.

> So there's basically no advantage to etc-overrides-non-etc unless one
> hasn't bothered to implement proper configuration file handling.

Advantages I mentioned earlier would still be there:
It's easier to see what is local non-default configuration. Original
default file is always available in a known location (and very easy to
revert to, temporarily for testing or permanently). You can use
".include /lib/defaultsfile" then override some value, which in most
cases is more maintainable than the 3-way merging required by
"traditional" conffiles.



-- 
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/1336681268.2227.112.camel@glyph.nonexistent.invalid

Re: Bug#672160: Directory /boot/console-setup

[Anton Zinoviev]

On Thu, May 10, 2012 at 07:45:21PM +0200, Sven Joachim wrote:
> 
> Maybe I'm missing something obvious, but /boot seems to be a very bad
> choice for the location, simply because it is not available any earlier
> than /var.

Ah, you are right.

So it seems only /etc is an option. Thanks.

Anton Zinoviev


-- 
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/20120510191339.ga8...@debian.lan

Re: RFC: OpenRC as Init System for Debian

[David Weinehall]

On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote:
> On 05/10/2012 04:52 AM, Steve McIntyre wrote:
> > No, really - please *do* do this. The fact that a lot of the software
> > coming out of RedHat development seems to be designed solely for their
> > use, including working around the missing/broken features of RPM, is
> > seriously annoying. Configuration belongs in /etc, we know this. We
> > have a well-designed and implemented set of tools in Debian based on
> > that standard.
> >   
> I agree 100% with the above.
> 
> On 05/10/2012 05:22 AM, Uoti Urpala wrote:
> > Josh Triplett provided multiple technical reasons why etc-overrides-lib
> > is preferable. The ONLY technical reason you gave to prefer traditional
> > conffiles was that there already is a "set of tools" for that in Debian.
> >   
> No, it's because this way, I am warned by the package manager of a change
> on the default file, and I can merge by hand when I see it. Otherwise, you
> are silently changing the default, and potentially, I will miss the new
> options.
> 
> Besides this, configuration files in /etc is written in the stones of
> our bible^Wpolicy-manual.

Has anyone argued for having the configuration files anywhere else?
It's all in the semantics of course, but to me, the configuration files
are the files that the administrator changes to change a configuration.
The files that go in /lib are the defaults.  If the admin wants to
override something they do so in /etc, just like before.

If the old file in /lib isn't equal to the new file being installed to
/lib, and there's a user supplied file in /etc rather than just the
default (which would only include the version in lib), then prompt the
user.  If the user is running a non-interactive upgrade, fire off an
e-mail or something.  For any major changes to the /lib files (stuff
that are likely to trigger user actions), NEWS.Debian should of course,
as usual, contain a heads up.

Just because something isn't supported currently in our tools doesn't
make it impossible to support it.  And debian-policy isn't set in stone.
Otherwise it wouldn't have last been revised in February 2012 :)


Regards, David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120510200439.gf10...@suiko.acc.umu.se

Re: RFC: OpenRC as Init System for Debian

[George Danchev]

On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
> Don Armstrong wrote:
> > On Thu, 10 May 2012, Uoti Urpala wrote:
> > > You're pretty much just saying that dpkg and helpers like ucf have
> > > implemented better functionality than rpm. I don't see how that's
> > > relevant to the discussion.
> > 
> > The reason why it is relevant is because
> 
> I don't see how the following would make this comparison with rpm relevant.

It was a comparison of the packaging system facilities to handle upgrades of 
the configuration files of the applications. This was initially started by you 
as a misguided comparison between etc-overrides-lib (apples) vs. dpkg conffiles 
(oranges). Basically you're mixing up packaging system facilities to handle 
upgrades/transitions of application configuration files with the styles of 
applications reading their own configuration files.

> >  in the etc-overrides-lib
> > 
> > model you are unable to trivially merge local changes with upstream or
> > packaging changes unless you add additional logic in the postinst to
> > handle etc-overrides-lib. Having configuration files in /etc and using
> > ucf or similar enables you to deal with this problem easily.
> 
> Yes, you do need some tool improvements to be able to alert the user
> about changes. This has been mentioned before. I don't think this would

You need to at least start reading some man-pages (a good start would be 
ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming suggestion 
like "improvements to be able to alert the user about changes". This is 
already there, and has been there for a long time, as also mentioned before. 
I'm pretty sure that merging techniques could be made even more smarter or, 
but "alerting the user" functionality has been there for a long time already.

> be hard to add though, and not overall harder than what is already
> implemented for traditional conffile handling; this is not a fundamental
> problem with the etc-overrides-lib model.
> 
> And as also mentioned before, the include option should reduce the
> number of cases where you need to do 3-way merging.

You don't seem to understand that style of reading of configuration files of 
the 
applications is in the realm of the applications themselves and packaging 
systems facilities which help handling upgrades of these application 
configuration files can not frivolously add "include" or any other convenient 
option directives you are suggesting to these application configuration files.

-- 
pub 4096R/0E4BD0AB 


-- 
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/201205102303.37863.danc...@spnet.net

Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

[Gergely Nagy]

Don Armstrong  writes:

> On Thu, 10 May 2012, Uoti Urpala wrote:
>> Don Armstrong wrote: 
>> > The reason why it is relevant is because [...]
>> 
>> I don't see how the following would make this comparison with rpm
>> relevant.
>
> This is debian-devel, and we're talking about configuration file
> handling in Debian, which makes ucf and dpkg relevant.
>
>> > Having configuration files in /etc and using ucf or similar
>> > enables you to deal with this problem easily.
>> 
>> Yes, you do need some tool improvements to be able to alert the user
>> about changes.
>
> Right. So for every package which does this, you have to check to see
> whether a configuration file in /etc has had it's corresponding
> non-etc configuration file changed, and then offer to merge them
> together.

FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already do
something *very* close to what etc-overrides-non-etc does. To the point
that changing a file under /etc/default, or adding a snippet to conf.d/
can break just as well when the underlying default changes as if that
upstream happened to be outside of /etc.

We do not handle that case either, and I don't see how the default being
outside of /etc would be any different. Except it's easier to follow,
since the default is never modified by the admin, while if it's in /etc
too, like in plenty of cases in the archive, both can change, and we end
up with even scarier situations that can't be resolved sanely.

> So there's basically no advantage to etc-overrides-non-etc unless one
> hasn't bothered to implement proper configuration file handling.

Then we already have a problem, because the conf.d/ and default stuff
suffer from the same problems, and they're used widely all over the
place.

-- 
|8]


-- 
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/87vck3de3i@luthien.mhp

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

George Danchev wrote:
> On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote:
> > The reason why most old applications do not follow that approach (at
> > least not yet) is pretty obvious: their authors never considered it.
> > etc-overrides-lib semantics have only become a seriously considered
> > alternative fairly recently.
> 
> Implying that a fairly simplistic semantics of providing two distinct 
> directories with configuration files, has never been considered for the last 
> 40 
> years and painting it as a revolution in the application development is 
> naive, 
> at best.

Someone certainly has considered it during the last 40 years. But most
people creating applications did not consider it when deciding the
default semantics of their application. Do you really want to seriously
argue this?

Your remark about "painting it as a revolution" seems to be completely
made up.


> > configuration format and 2) saying Debian should choose its preferred
> > configuration format based on the limitations of its packaging system,
> 
> Let me tell you a secret: Debian should not decide whether or not tens of 
> thousand of applications follow a particular style of reading their 
> configuration files. This is in the realm of application development and 
> anyone 
> should be free to choose their style. It would be a segregation if Debian 
> bans 
> applications simply because their style of reading configuration files looks 
> funny... and Debian does not segregate. This is not a secret.

Did you read what I was originally replying to? It talked about
symlinking the /lib and /etc directories to the same one. Debian would
not "ban" the application, but it _was_ about overriding the upstream
choice of configuration model.


> > You're pretty much just saying that dpkg and helpers like ucf have
> > implemented better functionality than rpm. I don't see how that's
> > relevant to the discussion. I don't think it makes the above comparison
> > any less valid. And generally, I don't think the packaging system issues
> > would be so difficult that they should have a major influence on what
> > configuration model to use.
> 
> What I was saying, I already wrote. Retelling it wrong is useless.

If you had some other point, it wasn't clear. And your reply certainly
does not clarify anything.

If you still want to reply, try to include more factual content or
arguments.


-- 
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/1336676978.2227.99.camel@glyph.nonexistent.invalid

etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

[Don Armstrong]

On Thu, 10 May 2012, Uoti Urpala wrote:
> Don Armstrong wrote: 
> > The reason why it is relevant is because [...]
> 
> I don't see how the following would make this comparison with rpm
> relevant.

This is debian-devel, and we're talking about configuration file
handling in Debian, which makes ucf and dpkg relevant.

> > Having configuration files in /etc and using ucf or similar
> > enables you to deal with this problem easily.
> 
> Yes, you do need some tool improvements to be able to alert the user
> about changes.

Right. So for every package which does this, you have to check to see
whether a configuration file in /etc has had it's corresponding
non-etc configuration file changed, and then offer to merge them
together.

Thus, when you fully implement etc-overrides-non-etc, you have to
handle configuration files in non-etc *exactly* as if they were in etc
to start with. [Lets not even start with trying to figure out how you
would handle deleting a non-etc configuration file when there's a
difference between a non-existent file and an empty one.]

So there's basically no advantage to etc-overrides-non-etc unless one
hasn't bothered to implement proper configuration file handling.


Don Armstrong

-- 
Your village called.
They want their idiot back.
 -- xkcd http://xkcd.com/c23.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120510192430.gc3...@rzlab.ucr.edu

Re: RFC: OpenRC as Init System for Debian

[Jean-Christophe Dubacq]

On 10/05/2012 21:12, Don Armstrong wrote:
> On Thu, 10 May 2012, Jean-Christophe Dubacq wrote:
>> I do not know about trivially merging changes in the
>> etc-overrides-lib model, but in the current model, I am presented
>> with the dpkg prompt about conffiles for some programs where I added
>> (or changed) only one line (off the top of my head: only the servers
>> list in roundcube, for example), and dpkg does not propose to merge
>> the two files: I am either stuck with keeping my old file, taking
>> the new, or using a shell.
> 
> This is because dpkg's conffile support currently does not do what ucf
> can do. Presumably this will be addressed eventually, but packages
> where this will be a significant problem are often already using ucf
> or similar.
> 
>> All these things are interactive and prevent unattended upgrades
>> without disruption of services.
> 
> It's basically not possible to have a non-interactive unattended
> upgrade without the possibility of interruptions of service without
> outside input as to the decisions that the package manager should be
> making. ucf and similar gets us closer, but at the end of the day,
> it's impossible to handle all possible configuration changes.
> 
I meant: I test on one server, then replicate the upgrade on other
servers. dpkg is lacking in the merge department, and the fact that
there is no good possibility to keep one's local changes and only those
is simply not helping the user.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: RFC: OpenRC as Init System for Debian

[Don Armstrong]

On Thu, 10 May 2012, Jean-Christophe Dubacq wrote:
> I do not know about trivially merging changes in the
> etc-overrides-lib model, but in the current model, I am presented
> with the dpkg prompt about conffiles for some programs where I added
> (or changed) only one line (off the top of my head: only the servers
> list in roundcube, for example), and dpkg does not propose to merge
> the two files: I am either stuck with keeping my old file, taking
> the new, or using a shell.

This is because dpkg's conffile support currently does not do what ucf
can do. Presumably this will be addressed eventually, but packages
where this will be a significant problem are often already using ucf
or similar.

> All these things are interactive and prevent unattended upgrades
> without disruption of services.

It's basically not possible to have a non-interactive unattended
upgrade without the possibility of interruptions of service without
outside input as to the decisions that the package manager should be
making. ucf and similar gets us closer, but at the end of the day,
it's impossible to handle all possible configuration changes.


Don Armstrong

-- 
Cheop's Law: Nothing ever gets built on schedule or within budget.
 -- Robert Heinlein _Time Enough For Love_ p242

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120510191207.gb3...@rzlab.ucr.edu

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Don Armstrong wrote:
> On Thu, 10 May 2012, Uoti Urpala wrote:
> > You're pretty much just saying that dpkg and helpers like ucf have
> > implemented better functionality than rpm. I don't see how that's
> > relevant to the discussion.
> 
> The reason why it is relevant is because

I don't see how the following would make this comparison with rpm relevant.

>  in the etc-overrides-lib
> model you are unable to trivially merge local changes with upstream or
> packaging changes unless you add additional logic in the postinst to
> handle etc-overrides-lib. Having configuration files in /etc and using
> ucf or similar enables you to deal with this problem easily.

Yes, you do need some tool improvements to be able to alert the user
about changes. This has been mentioned before. I don't think this would
be hard to add though, and not overall harder than what is already
implemented for traditional conffile handling; this is not a fundamental
problem with the etc-overrides-lib model.

And as also mentioned before, the include option should reduce the
number of cases where you need to do 3-way merging.



-- 
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/1336675601.2227.84.camel@glyph.nonexistent.invalid

Re: RFC: OpenRC as Init System for Debian

[Peter Samuelson]

[Uoti Urpala]
> The reason why most old applications do not follow that approach (at
> least not yet) is pretty obvious: their authors never considered it.
> etc-overrides-lib semantics have only become a seriously considered
> alternative fairly recently.

If I'm not mistaken, I first saw this sort of arrangement in CDE, circa
1998.  Maybe that's considered "recent".  Sure, nobody's heard of it
anymore, but it was pretty widespread back in the day.

There were a lot of things I didn't like about CDE, and this was one of
them.

> From your following text it seems you mean the comparison between 1)
> criticizing Red Hat for (allegedly) letting packaging system
> limitations affect the choice of configuration format and 2) saying
> Debian should choose its preferred configuration format based on the
> limitations of its packaging system

That's ... a misleading way of looking at it.  There is a tension
between minor upgrades and major upgrades.

1. Major upgrades: default config may change noticeably, and a custom
   config forked from the default may need to be updated to work
   optimally or even correctly.

- Red Hat apparently has no reason to care about this case, if they
  don't support major upgrades at all.

- This is where "copy to /etc" can be bad.  It's not trivial for
  the packaging to determine that the local copy needs attention,
  either to handle it automatically, or to alert the local admin.

2. Minor upgrades, or reinstall: default config rarely changes, and
   does not change incompatibly.  E.g., a security upload.

- Red Hat _does_ need to support this case.

- This is where "copy to /etc" works.  It prevents the packaging
  system from overwriting your local config changes.

- Apparently RPM packaging and tooling has a history of overwriting
  local config changes.  I don't know the details.  But if true,
  "copy to /etc" would seem like an attractive workaround.

- However, Debian's packaging has had policy and tooling to avoid
  overwriting local changes for about 20 years, so it should not be
  surprising that we don't see much upside here, only the downside
  (mentioned in point 1).


-- 
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/20120510190217.gc2...@p12n.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/10/2012 07:13 AM, Uoti Urpala wrote:
> I have given technical reasons to prefer etc-overrides-lib semantics.
> You failed to address any of the reasons I or others have given. Instead
> you started by bashing Red Hat, and then gave as your only reason to
> prefer traditional conffile semantics the same motivation you had just
> alleged Red Hat of having and had bashed them for. If you post
> fallacious nonsense, there usually isn't much more to say to that except
> point out that it IS fallacious nonsense.
>
> If you want to have a constructive discussion, then try to explain what
> you think is wrong with the arguments for etc-overrides-libs, or what
> technical advantages you think the traditional conffile model has which
> would be more important.
>   
Come on!

Don't assume that people are bad, or have bad intend. That's how
discussions are going the wrong way.

Probably, Steve assumed that you understood the reasons why he
liked the *Debian* way, without much need to explain what's
written in the stones of our policy-manual...

Thomas


-- 
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/4fac0e79.4090...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/10/2012 07:01 AM, Fernando Lemos wrote:
> I've seen people mention that the way udev and systemd do config files
> is really motivated by limitations in RH's packaging tools. Maybe
> that's the case, maybe not.
It's *not*! It's a difference in *policy*. :)

RH's policy is that you should never prompt the user for something
when installing a package. We have debconf, ucf, etc. because we
want the user to be prompted *if* he wants to (and I personally do
want to, so I don't run in non-interactive mode).

Thomas


-- 
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/4fac0d9f.5070...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Raphael Hertzog]

On Thu, 10 May 2012, David Weinehall wrote:
> On Wed, May 09, 2012 at 03:47:21PM +0200, Gergely Nagy wrote:
> > Such a tool would certainly be very useful, but doing it right would be
> > fairly hard, as far as I see.
> > 
> > And it would require assistance from at least the package maintainer, to
> > mark in which versions the unit file under /lib changed, so that it can
> > trigger only when appropriate and not on every upgrade.
> > 
> > (And there's possibly other corner cases to consider, but they escape me
> > right now..)
> 
> if [  -ot  ]; then
>fi

That's not enough. The timestamp of the file in a package is unrelated
to the time of its last installation.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20120510184745.ge8...@rivendell.home.ouaza.com

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

Marco d'Itri wrote:
> On May 10, Bjørn Mork  wrote:
> 
> > Agree.  Copying a large set of default policies into /etc just because
> > they *can* be overridden is not user friendly.  And it does not make the
> > defaults any more configuration either. It just hides important local
> > changes and makes it difficult both for the user and the application
> > itself to distinguish between defaults and configuration overrides.

> Wrong:

You're not addressing what he said about the generally desirable /etc
semantics at all, only talking about what current Debian tools would do
without modifications. Do you have a reason to oppose beyond "this would
need some tool changes"?

>  since you have to copy the whole file to override it,

Wrong: as mentioned in this thread before, one of the advantages of the
etc-overrides-lib model is the option of having a file in /etc that
first includes the one in /lib, then overrides just one particular
value. This allows handling more updates without needing manual changes,
as you can automatically pick up other updated values while keeping the
override, without needing to do 3-way merges.

> and files 
> in /lib have no conffiles handling, after an upgrade you will not know 
> what was changed by you and what was changed upstream.

IIRC dpkg does not store the original file (while ucf does), so
currently you always lose track of "what was changed by you" unless you
make a copy manually (or with extra tools like etckeeper). Anyway, this
is about the specifics of what is supported by Debian tools now, not
about any intrinsic problem with the behavior.

> Obviously this is not a problem for Red Hat since they do not support 
> upgrades between major releases.

Why would this cause problems for Debian, except at most needing some
changes to tools to better support this case? Or do you think
implementing that would be hard?



-- 
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/1336674656.2227.72.camel@glyph.nonexistent.invalid

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/10/2012 04:52 AM, Steve McIntyre wrote:
> No, really - please *do* do this. The fact that a lot of the software
> coming out of RedHat development seems to be designed solely for their
> use, including working around the missing/broken features of RPM, is
> seriously annoying. Configuration belongs in /etc, we know this. We
> have a well-designed and implemented set of tools in Debian based on
> that standard.
>   
I agree 100% with the above.

On 05/10/2012 05:22 AM, Uoti Urpala wrote:
> Josh Triplett provided multiple technical reasons why etc-overrides-lib
> is preferable. The ONLY technical reason you gave to prefer traditional
> conffiles was that there already is a "set of tools" for that in Debian.
>   
No, it's because this way, I am warned by the package manager of a change
on the default file, and I can merge by hand when I see it. Otherwise, you
are silently changing the default, and potentially, I will miss the new
options.

Besides this, configuration files in /etc is written in the stones of
our bible^Wpolicy-manual.

Thomas


-- 
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/4fac0c9d.2070...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/10/2012 12:14 AM, Uoti Urpala wrote:
> Not having the files in /etc by default does have technical advantages.
> It's easier to see what is local non-default configuration. Original
> default file is always available in a known location (and very easy to
> revert to, temporarily for testing or permanently).
Actually, what you are talking about is a very good candidate
for /usr/share/doc//examples, not at all for a weird
things with config files in /lib overridden by /etc, which really,
isn't the Debian way.

On 05/10/2012 12:14 AM, Uoti Urpala wrote:
> which in most
> cases is more maintainable than the 3-way merging required by
> "traditional" conffiles.
>   

The 3-way merging at least prompts you that something is changing
so you have a chance to update your config file by hand the way you
think is best. If the package updates the config file in /lib without
prompting, then potentially, the user will not be aware of the
change.

In a RPM based environment, this behavior is fine, because that's
the RPM way to never prompt anything to the user (see *.rpmsave
or *.rpmnew files). But this is exactly why I don't like RPM systems!

On 05/10/2012 12:14 AM, Uoti Urpala wrote:
> It's also preferable to avoid unnecessarily differing from the setup
> used on other distros.
>   

IMO, it's preferable to do things the same way on all packages
in Debian. I don't see why systemd should be different from any
other package we have in the Debian archve. If systemd can't
adapt to our ways to do things, with configuration files in /etc,
then I'm betting that many will complain (IMO rightly) about
policy violation.

(just my 2 cents, as I still have on my todo to try systemd...)

Cheers,

Thomas


-- 
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/4fac0ab0.8040...@debian.org

Re: RFC: OpenRC as Init System for Debian

[Jean-Christophe Dubacq]

On 10/05/2012 19:55, Don Armstrong wrote:
> On Thu, 10 May 2012, Uoti Urpala wrote:
>> You're pretty much just saying that dpkg and helpers like ucf have
>> implemented better functionality than rpm. I don't see how that's
>> relevant to the discussion.
> 
> The reason why it is relevant is because in the etc-overrides-lib
> model you are unable to trivially merge local changes with upstream or
> packaging changes unless you add additional logic in the postinst to
> handle etc-overrides-lib. Having configuration files in /etc and using
> ucf or similar enables you to deal with this problem easily.
> 
> 
> Don Armstrong
> 
I do not know about trivially merging changes in the etc-overrides-lib
model, but in the current model, I am presented with the dpkg prompt
about conffiles for some programs where I added (or changed) only one
line (off the top of my head: only the servers list in roundcube, for
example), and dpkg does not propose to merge the two files: I am either
stuck with keeping my old file, taking the new, or using a shell. All
these things are interactive and prevent unattended upgrades without
disruption of services.

When the merging possibilities of dpkg will have been enhanced, I may
reconsider, but currently, I prefer the
etc-overrides-lib-only-where-present as superior to the current state.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: RFC: OpenRC as Init System for Debian

[George Danchev]

On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote:
> George Danchev wrote:
> > On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
> > > Steve McIntyre wrote:
> > > > No, really - please *do* do this. The fact that a lot of the software
> > > > coming out of RedHat development seems to be designed solely for
> > > > their use, including working around the missing/broken features of
> > > > RPM, is seriously annoying. Configuration belongs in /etc, we know
> > > > this. We have a well-designed and implemented set of tools in Debian
> > > > based on that standard.
> > > 
> > > Machine-specific configuration belongs in /etc. The default behavior of
> > > the tools doesn't.
> > 
> > For some reason or another the vast majority of applications have not
> > been following this approach. I'm not going to argue whether is makes
> > sense or not.
> 
> The reason why most old applications do not follow that approach (at
> least not yet) is pretty obvious: their authors never considered it.
> etc-overrides-lib semantics have only become a seriously considered
> alternative fairly recently.

Implying that a fairly simplistic semantics of providing two distinct 
directories with configuration files, has never been considered for the last 40 
years and painting it as a revolution in the application development is naive, 
at best.

> > > Josh Triplett provided multiple technical reasons why etc-overrides-lib
> > > is preferable. The ONLY technical reason you gave to prefer traditional
> > > conffiles was that there already is a "set of tools" for that in
> > > Debian.
> > 
> > Your comparison is misguided.
> 
> Which comparison are you talking about? From your following text it
> seems you mean the comparison between 1) criticizing Red Hat for
> (allegedly) letting packaging system limitations affect the choice of
> configuration format and 2) saying Debian should choose its preferred
> configuration format based on the limitations of its packaging system,

Let me tell you a secret: Debian should not decide whether or not tens of 
thousand of applications follow a particular style of reading their 
configuration files. This is in the realm of application development and anyone 
should be free to choose their style. It would be a segregation if Debian bans 
applications simply because their style of reading configuration files looks 
funny... and Debian does not segregate. This is not a secret.

> though that comparison does not appear in the text you quoted.
>
> > The vast majority of applications do not follow etc-overrides-lib (some
> > will never follow) so their configuration files should be properly
> > managed as well, and dpkg's conffiles facility, dpkg's maintainer
> > scripts in conjunction with things like ucf and debconf are quite
> > powerful mechanisms to employ which have been proven for the last
> > decade. Contrast this to the rpm systems trashing locally modified
> > configuration files in /etc/ for the last decade. It is also trivial for
> > the debian packages to contain default configuration files so users and
> > tools could refer to them on demand, and this has nothing to do with the
> > packaging system itself.
> 
> You're pretty much just saying that dpkg and helpers like ucf have
> implemented better functionality than rpm. I don't see how that's
> relevant to the discussion. I don't think it makes the above comparison
> any less valid. And generally, I don't think the packaging system issues
> would be so difficult that they should have a major influence on what
> configuration model to use.

What I was saying, I already wrote. Retelling it wrong is useless.

> > OTOH, applications following etc-overrides-lib happily run on Debian
> > systems in the way they run on others. It is not like the semantics of
> > separating the default and locally modified configuration files in two
> > directories is some sort of giant invention, never heard of before. It
> > is also trivial to guess that their configuration files could also be
> > managed by calling tools from dpkg's maintainer scripts in order to
> > communicate with the user or provide assistance
> 
> Yes, nobody has brought up reasons why this wouldn't work.

Now, the hard work remains: teach all applcations out there to follow the etc-
overrides-lib _semantics_. Sure, thing, I'm thrilled, at all.

-- 
pub 4096R/0E4BD0AB 


-- 
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/201205102103.19021.danc...@spnet.net

Re: Directory /boot/console-setup

[Sven Joachim]

On 2012-05-10 19:45 +0200, Roger Leigh wrote:

> On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote:
>> [Please preserve the CC to 672...@bugs.debian.org because I am not 
>> subscribed to debian-devel.]
>> 
>> First the problem in few words.  The package console-setup needs an 
>> access to a directory similar to /var very early during the boot process 
>> - when /var is not yet mounted.  Currently it creates files in the 
>> directory /etc/console-setup.
>
> We created /run for exactly this purpose.  Create /run/console-setup
> and put what you need inside there.

AIUI the data is not volatile, and it needs to be read early in the boot
process, that's why /var was not suitable.

Cheers,
   Sven


-- 
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/87havn9b00@turtle.gmx.de

Re: RFC: OpenRC as Init System for Debian

[Don Armstrong]

On Thu, 10 May 2012, Uoti Urpala wrote:
> You're pretty much just saying that dpkg and helpers like ucf have
> implemented better functionality than rpm. I don't see how that's
> relevant to the discussion.

The reason why it is relevant is because in the etc-overrides-lib
model you are unable to trivially merge local changes with upstream or
packaging changes unless you add additional logic in the postinst to
handle etc-overrides-lib. Having configuration files in /etc and using
ucf or similar enables you to deal with this problem easily.


Don Armstrong

-- 
THERE IS NO GRAVITY THE WORLD SUCKS
 -- Vietnam War Penquin Lighter
http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120510175506.gx3...@rzlab.ucr.edu

Re: RFC: OpenRC as Init System for Debian

[Jean-Christophe Dubacq]

On 10/05/2012 19:34, Marco d'Itri wrote:
> On May 10, Bjørn Mork  wrote:
> 
>> Agree.  Copying a large set of default policies into /etc just because
>> they *can* be overridden is not user friendly.  And it does not make the
>> defaults any more configuration either. It just hides important local
>> changes and makes it difficult both for the user and the application
>> itself to distinguish between defaults and configuration overrides.
> Wrong: since you have to copy the whole file to override it, and files 
> in /lib have no conffiles handling, after an upgrade you will not know 
> what was changed by you and what was changed upstream.
> Obviously this is not a problem for Red Hat since they do not support 
> upgrades between major releases.
> 
There are cases where file in /etc overrides only the directives present
in /etc and not the rest. I prefer this way.

-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: Directory /boot/console-setup

[Roger Leigh]

On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote:
> [Please preserve the CC to 672...@bugs.debian.org because I am not 
> subscribed to debian-devel.]
> 
> First the problem in few words.  The package console-setup needs an 
> access to a directory similar to /var very early during the boot process 
> - when /var is not yet mounted.  Currently it creates files in the 
> directory /etc/console-setup.

We created /run for exactly this purpose.  Create /run/console-setup
and put what you need inside there.  You'll need to follow the
advice in http://wiki.debian.org/ReleaseGoals/RunDirectory .
You basically just need to have a Depends on
initscripts (>= 2.88dsf-13.3) and you're good to go.  Don't store
megabytes of data in here though, since it's stored in virtual
memory on most systems.


Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120510174518.gk23...@codelibre.net

Re: Bug#672160: Directory /boot/console-setup

[Sven Joachim]

On 2012-05-10 18:43 +0200, Anton Zinoviev wrote:

> [Please preserve the CC to 672...@bugs.debian.org because I am not 
> subscribed to debian-devel.]
>
> First the problem in few words.  The package console-setup needs an 
> access to a directory similar to /var very early during the boot process 
> - when /var is not yet mounted.  Currently it creates files in the 
> directory /etc/console-setup.  As a result when the package is purged it 
> is impossible to tell which files in /etc/console-setup are 
> automatically generated (so they have to be removed) and which are put 
> there by the admin (so we are not permitted to remove them).
>
> One possible solution is to generate the files in a directory named 
> /etc/console-setup/.cache and to put a file /etc/console-setup/.cache/README
> explaining the purpose of this directory and warning the admin that the 
> package is free to remove or overwrite at any time any files in this 
> directory.
>
> Please don't complain that this is a policy violation. :) I think at the 
> moment there is no solution of the problem without policy violation and 
> the packages kbd, console-tools and console-setup have been happily 
> doing policy violations regarding /etc since the very first version of 
> Debian.
>
> The second solution I propose is to generate the files in a directory 
> /boot/console-setup.  After all the whole need of such directory arises 
> due to the specifics of the boot process.

Maybe I'm missing something obvious, but /boot seems to be a very bad
choice for the location, simply because it is not available any earlier
than /var.

Cheers,
   Sven


-- 
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/87sjf87wwe@turtle.gmx.de

Re: RFC: OpenRC as Init System for Debian

[Marco d'Itri]

On May 10, Bjørn Mork  wrote:

> Agree.  Copying a large set of default policies into /etc just because
> they *can* be overridden is not user friendly.  And it does not make the
> defaults any more configuration either. It just hides important local
> changes and makes it difficult both for the user and the application
> itself to distinguish between defaults and configuration overrides.
Wrong: since you have to copy the whole file to override it, and files 
in /lib have no conffiles handling, after an upgrade you will not know 
what was changed by you and what was changed upstream.
Obviously this is not a problem for Red Hat since they do not support 
upgrades between major releases.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Directory /boot/console-setup

[Anton Zinoviev]

[Please preserve the CC to 672...@bugs.debian.org because I am not 
subscribed to debian-devel.]

First the problem in few words.  The package console-setup needs an 
access to a directory similar to /var very early during the boot process 
- when /var is not yet mounted.  Currently it creates files in the 
directory /etc/console-setup.  As a result when the package is purged it 
is impossible to tell which files in /etc/console-setup are 
automatically generated (so they have to be removed) and which are put 
there by the admin (so we are not permitted to remove them).

One possible solution is to generate the files in a directory named 
/etc/console-setup/.cache and to put a file /etc/console-setup/.cache/README
explaining the purpose of this directory and warning the admin that the 
package is free to remove or overwrite at any time any files in this 
directory.

Please don't complain that this is a policy violation. :) I think at the 
moment there is no solution of the problem without policy violation and 
the packages kbd, console-tools and console-setup have been happily 
doing policy violations regarding /etc since the very first version of 
Debian.

The second solution I propose is to generate the files in a directory 
/boot/console-setup.  After all the whole need of such directory arises 
due to the specifics of the boot process.

Personally, I think I prefer /boot to /etc.

Some additional info: most of the time the package requires only 
read-only access to this directory.  Write-access is required only in 
the following occasions:

1. when the admin is dpkg-reconfiguring the package
2. during the first reboot (but not too early in the boot process) if 
the admin has edited the configuration files of console-setup by hand 
and he has not used the command "setupcon --save"
3. when the admin uses the command "setupcon --save"

Anton Zinoviev



-- 
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/20120510164346.gc3...@logic.fmi.uni-sofia.bg

Re: RFC: OpenRC as Init System for Debian

[David Weinehall]

On Wed, May 09, 2012 at 03:47:21PM +0200, Gergely Nagy wrote:
> Tollef Fog Heen  writes:
> 
> > ]] Philipp Kern 
> >
> >> You will not, however, get a conffile update prompt when the system
> >> file changes (e.g. to update your own local copy to incorporate the
> >> fix).
> >
> > This is something I'm pondering if we should handle in either a systemd
> > trigger or a tool that packages shipping systemd files can call to tell
> > the user about any changes.  (Basically a wrapper around ucf, probably.)
> 
> Such a tool would certainly be very useful, but doing it right would be
> fairly hard, as far as I see.
> 
> And it would require assistance from at least the package maintainer, to
> mark in which versions the unit file under /lib changed, so that it can
> trigger only when appropriate and not on every upgrade.
> 
> (And there's possibly other corner cases to consider, but they escape me
> right now..)

if [  -ot  ]; then
 /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120510171250.ge10...@suiko.acc.umu.se

Re: RFC: OpenRC as Init System for Debian

[Uoti Urpala]

George Danchev wrote:
> On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
> > Steve McIntyre wrote:
> > > No, really - please *do* do this. The fact that a lot of the software
> > > coming out of RedHat development seems to be designed solely for their
> > > use, including working around the missing/broken features of RPM, is
> > > seriously annoying. Configuration belongs in /etc, we know this. We
> > > have a well-designed and implemented set of tools in Debian based on
> > > that standard.
> > 
> > Machine-specific configuration belongs in /etc. The default behavior of
> > the tools doesn't.
> 
> For some reason or another the vast majority of applications have not been 
> following this approach. I'm not going to argue whether is makes sense or not.

The reason why most old applications do not follow that approach (at
least not yet) is pretty obvious: their authors never considered it.
etc-overrides-lib semantics have only become a seriously considered
alternative fairly recently.


> > Josh Triplett provided multiple technical reasons why etc-overrides-lib
> > is preferable. The ONLY technical reason you gave to prefer traditional
> > conffiles was that there already is a "set of tools" for that in Debian.
> 
> Your comparison is misguided.

Which comparison are you talking about? From your following text it
seems you mean the comparison between 1) criticizing Red Hat for
(allegedly) letting packaging system limitations affect the choice of
configuration format and 2) saying Debian should choose its preferred
configuration format based on the limitations of its packaging system,
though that comparison does not appear in the text you quoted.

> The vast majority of applications do not follow etc-overrides-lib (some will 
> never follow) so their configuration files should be properly managed as 
> well, 
> and dpkg's conffiles facility, dpkg's maintainer scripts in conjunction with 
> things like ucf and debconf are quite powerful mechanisms to employ which 
> have 
> been proven for the last decade. Contrast this to the rpm systems trashing 
> locally modified configuration files in /etc/ for the last decade. It is also 
> trivial for the debian packages to contain default configuration files so 
> users 
> and tools could refer to them on demand, and this has nothing to do with the 
> packaging system itself.

You're pretty much just saying that dpkg and helpers like ucf have
implemented better functionality than rpm. I don't see how that's
relevant to the discussion. I don't think it makes the above comparison
any less valid. And generally, I don't think the packaging system issues
would be so difficult that they should have a major influence on what
configuration model to use.

> OTOH, applications following etc-overrides-lib happily run on Debian systems 
> in the way they run on others. It is not like the semantics of separating the 
> default and locally modified configuration files in two directories is some 
> sort 
> of giant invention, never heard of before. It is also trivial to guess that 
> their configuration files could also be managed by calling tools from dpkg's 
> maintainer scripts in order to communicate with the user or provide 
> assistance 

Yes, nobody has brought up reasons why this wouldn't work.



-- 
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/1336668798.2227.58.camel@glyph.nonexistent.invalid

Re: Switch from xz-utils to liblzma in dpkg Pre-Depends

[Guillem Jover]

Hi,

On Mon, 2011-05-16 at 06:19:48 +0200, Guillem Jover wrote:
> As I'd like to change a Pre-Depends in dpkg, I'm bringing this up here
> for discussion, as per policy §3.5 and given dpkg “Essential: yes”
> nature.
> 
> 
> As mentioned in [0] some time ago, I'd like to switch the Pre-Depends
> from the current xz-utils commands to use the liblzma shared library,
> (with a patch provided by Jonathan Nieder). This will reduce the
> pseudo-essential package set and installed size slightly, and it
> will also allow for speed up improvements in the future.
> 
>   [0] 
> 
> There might be packages now implicitly depending on xz-utils given
> that it's being pulled by dpkg, but those are buggy and should be
> fixed regardless.
> 
> If there's no strong reasons not to, I'd like to include this for
> 1.16.1, as part of the dpkg buffer api rework needed for multiarch,
> the conffiledb and automatic checksum generation.

I'll be including this in the upcoming dpkg 1.16.4 release.

thanks,
guillem


-- 
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/20120510162009.ga25...@gaara.hadrons.org

ITP: libzeromq-perl -- A ZeroMQ2 wrapper for Perl

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: "Harlan Lieberman-Berg" 

Package name:   libzeromq-perl
Version:0.21
Upstream Author:Daisuke Maki 
URL:http://search.cpan.org/dist/ZeroMQ/
License:GPL-1+ or Artistic
Programming Lang:   Perl
Description:A ZeroMQ2 wrapper for Perl

The ZeroMQ module is a wrapper of the 0MQ message passing library for Perl.
It is a thin wrapper around the C API.

ZeroMQ is an intelligence socket library that acts like a concurrency
framework.  It is faster than TCP for clustered products and supercomputing,
carrying messages across inproc, IPC, TCP and multicast.  It can connect
N-N via fanout, pubsub, pipeline, request-reply, and several other models.


-- 
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/cabjrnbewydejyf-57khn5wmgwwtbptn_buextm+bl75smcw...@mail.gmail.com

ITP: libzeromq-perl -- A ZeroMQ2 wrapper for Perl

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: "Harlan Lieberman-Berg" 

Package name:   libzeromq-perl
Version:0.21
Upstream Author:Daisuke Maki 
URL:http://search.cpan.org/dist/ZeroMQ/
License:GPL-1+ or Artistic
Programming Lang:   Perl
Description:A ZeroMQ2 wrapper for Perl

The ZeroMQ module is a wrapper of the 0MQ message passing library for Perl.
It is a thin wrapper around the C API.

ZeroMQ is an intelligence socket library that acts like a concurrency
framework.  It is faster than TCP for clustered products and supercomputing,
carrying messages across inproc, IPC, TCP and multicast.  It can connect
N-N via fanout, pubsub, pipeline, request-reply, and several other models.


-- 
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/cabjrnbexvattpmelfr_am9srye1bgwdczb87yyyq5bp7zua...@mail.gmail.com

Re: RFC: OpenRC as Init System for Debian

[George Danchev]

On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
> Steve McIntyre wrote:
> > Josh Triplett wrote:
> > >Marco d'Itri wrote:
> > >> The more I think about it, the more I suspect that the correct
> > >> solution would be to just symlink /lib/udev/rules.d/ to
> > >> /etc/udev/rules.d/ and so on.
> > >
> > >Please don't.  As a user, I find it highly preferable for packages to
> > >install their default configuration in /lib and just have overrides in
> > >/etc, and I'd love to see that trend continue.  That setup lets me
> > >trivially construct personal configuration packages that ship the
> > >overriding files in /etc, without having to play ugly games with
> > >dpkg-divert of conffiles.  It also means that I don't get a pile of
> > >noise in etckeeper from all the upgrades of default configurations, so
> > >that my commits to etckeeper primarily consist of my own local changes.
> > 
> > No, really - please *do* do this. The fact that a lot of the software
> > coming out of RedHat development seems to be designed solely for their
> > use, including working around the missing/broken features of RPM, is
> > seriously annoying. Configuration belongs in /etc, we know this. We
> > have a well-designed and implemented set of tools in Debian based on
> > that standard.
> 
> Machine-specific configuration belongs in /etc. The default behavior of
> the tools doesn't.

For some reason or another the vast majority of applications have not been 
following this approach. I'm not going to argue whether is makes sense or not.

> Josh Triplett provided multiple technical reasons why etc-overrides-lib
> is preferable. The ONLY technical reason you gave to prefer traditional
> conffiles was that there already is a "set of tools" for that in Debian.

Your comparison is misguided.

The vast majority of applications do not follow etc-overrides-lib (some will 
never follow) so their configuration files should be properly managed as well, 
and dpkg's conffiles facility, dpkg's maintainer scripts in conjunction with 
things like ucf and debconf are quite powerful mechanisms to employ which have 
been proven for the last decade. Contrast this to the rpm systems trashing 
locally modified configuration files in /etc/ for the last decade. It is also 
trivial for the debian packages to contain default configuration files so users 
and tools could refer to them on demand, and this has nothing to do with the 
packaging system itself.

OTOH, applications following etc-overrides-lib happily run on Debian systems 
in the way they run on others. It is not like the semantics of separating the 
default and locally modified configuration files in two directories is some 
sort 
of giant invention, never heard of before. It is also trivial to guess that 
their configuration files could also be managed by calling tools from dpkg's 
maintainer scripts in order to communicate with the user or provide assistance 

> Who's the one choosing his preferred configuration format based on the
> limitations of his preferred packaging system here? Hint: it's not Red
> Hat.

You're good, but I'd better watch Peter Sellers, honestly.

-- 
pub 4096R/0E4BD0AB 


-- 
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/201205101802.37898.danc...@spnet.net

Re: RFC: OpenRC as Init System for Debian

[Kris Deugau]

Steve McIntyre wrote:
> No, really - please *do* do this. The fact that a lot of the software
> coming out of RedHat development seems to be designed solely for their
> use, including working around the missing/broken features of RPM,

I'm curious exactly what you mean by this, since my own experience has
been that rpm is more flexible than dpkg.

-kgd, longtime RedHat-er torn between a distro that I get along with and
a distro with at least three kitchen sinks included


-- 
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/4fabcd92.4060...@vianet.ca

Bug#672375: ITP: cloud-init

[Charles Plessy]

Package: wnpp

Hello everybody,

I was reminded to send an ITP for cloud-init, so that the progress in packaging
can be followed.  Here are prospective control and copyright files.

I tried to rework the description using 
https://help.ubuntu.com/community/CloudInit.

Your comments, proofreading, etc. are very welcome.

Cheers,

-- Charles

Source: cloud-init
Section: admin
Priority: optional
Maintainer: Python Applications Packaging Team 

Uploaders: Charles Plessy 
Build-Depends: cdbs (>= 0.4.90~),
   debhelper (>= 9),
   po-debconf,
   pyflakes,
   pylint,
   python (>= 2.6.6-3~),
   python-nose,
   python-mocker,
Standards-Version: 3.9.3
Homepage: https://launchpad.net/cloud-init
Vcs-Svn: svn://svn.debian.org/python-apps/packages/cloud-init/trunk/
Vcs-Browser: http://svn.debian.org/websvn/python-apps/packages/cloud-init/trunk/

Package: cloud-init
Architecture: all
Depends: cloud-utils,
 ifupdown (>= 0.6.10ubuntu5),
 procps,
 python,
 python-cheetah,
 python-configobj,
 python-oauth,
 python-software-properties,
 python-yaml,
 ${misc:Depends},
 ${python:Depends}
Description: configuration and customization of cloud instances
 System to handle early initialization of a cloud instance. Cloud-init can for
 example set a default locale and a host name, generate SSH private host keys,
 add SSH keys to a user's .ssh/authorized_keys so they can log in, and set up
 ephemeral mount points.
 .
 Cloud-init's behavior can be configured via user-data, given by the user at
 instance launch time.


Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: 
https://launchpad.net/cloud-init/trunk/0.6.3/+download/cloud-init-0.6.3.tar.gz

Files: *
Copyright: © 2009-2012, Canonical Ltd.
   © 2012 Hewlett-Packard Development Company, L.P.
   © 2012 Cosmin Luta
License: GPL-3
 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License version 3, as
 published by the Free Software Foundation.
 .
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 .
 You should have received a copy of the GNU General Public License
 along with this program.  If not, see .
 .
 The complete text of the GPL version 3 can be seen in
 /usr/share/common-licenses/GPL-3.

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan



--
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/20120510133051.ga2...@merveille.plessy.net

Re: RFC: OpenRC as Init System for Debian

[Bjørn Mork]

Uoti Urpala  writes:

> Machine-specific configuration belongs in /etc. The default behavior of
> the tools doesn't.

Agree.  Copying a large set of default policies into /etc just because
they *can* be overridden is not user friendly.  And it does not make the
defaults any more configuration either. It just hides important local
changes and makes it difficult both for the user and the application
itself to distinguish between defaults and configuration overrides.

A default setting does not count as configuration until it is changed,
IMHO. 


Bjørn


--
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/87397844h3@nemi.mork.no

Bug#672360: ITP: glue -- Simple command line tool to generate CSS sprites.

[Angel Abad]

Package: wnpp
Severity: wishlist
Owner: Angel Abad 

* Package name: glue
  Version : 0.2.5
  Upstream Author : Jorge Bastida 
* URL : https://github.com/jorgebastida/glue
* License : BSD
  Programming Lang: Python
  Description : Simple command line tool to generate CSS sprites.

Glue is a simple command line tool to generate CSS sprites using any
kind of source images like PNG, JPEG or GIF. Glue will generate a
unique PNG file containing every source image and a CSS file including
the necessary CSS classes to use the sprite.



-- 
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/20120510111712.8930.38671.reportbug@bangalore

Re: RFC: OpenRC as Init System for Debian

[Jon Dowland]

On Wed, May 09, 2012 at 12:46:40PM -0700, Josh Triplett wrote:
> It also means that I don't get a pile of noise in etckeeper from all the
> upgrades of default configurations, so that my commits to etckeeper primarily
> consist of my own local changes.

I don't personally use etckeeper but it strikes me that one advantage of
storing your /etc in a VCS would surely be being able to distinguish local and
system changes, perhaps storing each in a separate branch (with the merged
result matching the live /etc).  If etckeeper doesn't do this now, perhaps it
could do in future.


-- 
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/20120510093304.GK8272@debian

Bug#672346: ITP: lua-penlight -- general purpose library for the Lua language

[Enrico Tassi]

Package: wnpp
Severity: wishlist
Owner: Enrico Tassi 

* Package name: lua-penlight
  Version : 1.0.2
  Upstream Author : Steve Donovan
* URL : http://stevedonovan.github.com/Penlight/api/index.html
* License : MIT
  Programming Lang: Lua
  Description : Collection of general purpose libraries for the Lua
language
A set of pure Lua libraries focusing on input data handling (such as reading
configuration files), functional programming (such as map, reduce, placeholder
expressions,etc), and OS path management. Much of the functionality is inspired
by the Python standard libraries.



-- 
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/20120510092429.26218.7278.reportbug@localhost.localdomain

Bug#672344: ITP: python-lua -- library for using lua scripts from python

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: Bas Wijnen 

* Package name: python-lua
  Version : 0.1
  Upstream Author : Bas Wijnen 
* URL : None, first publication will be in Debian
* License : GPL-3+
  Programming Lang: Python
  Description : library for using lua scripts from python

This library provides an interface for using lua scripts from python.
It can call lua functions, pass any type of objects, including python
functions, which can be called from lua.



-- 
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/20120510091109.16596.74246.reportbug@localhost

Re: upstream shared library major versions

[Simon McVittie]

On 10/05/12 01:04, Brian May wrote:
> Should I be changing
> the library name from libdar64-5 to libdar64-5000? Or does this change
> reflect some sort of misunderstanding in how library versions work?

Given that he doesn't understand "why libtool sets the first digit to
current-age (5000 instead of 5002)" he might well not be understanding
how libtool versioning works. Feel free to forward this email if you
find it helpful.

The thing to understand is that libtool versioning is not the same
conceptual model as Linux library versioning. This is rather
unfortunate, since Linux-style library versioning is fairly ubiquitous,
and considerably easier to understand than Libtool's...

He's using a three-level versioning scheme corresponding to the library
versioning you'd get in Linux if you managed the versions by hand, which
he calls major/medium/minor, in which incompatible ABI changes increment
$major, ABI additions increment $medium, bugfixes increment $minor, and
incrementing anything zeroes the smaller parts. (It's more common to
call this major/minor/micro, but I'll use his terminology here.)

Libtool uses three numbers (current/revision/age), but they're not a
hierarchy. The idea is that you're saying "this is ABI version $current,
and it's backwards-compatible with all versions from $current down to
$current-$age" - so that's where the current - age in the SONAME comes
from. Incompatible ABI changes increment $current and zero $age, ABI
additions increment $current *and* $age, bugfixes increment $revision,
and incrementing anything except $revision zeroes it.

On platforms where the on-disk library name has a
major.medium.micro-style version (including Linux, anything else GNU,
and Darwin) or just a major version (including Windows), Libtool derives
a major.medium.micro-style version from the current/revision/age:

major = current - age
medium = age
micro = revision

It is in fact possible to use "-version-number $major:$medium:$micro"
instead of "-version-info $current:$revision:$age" if that fits your
mental model better, as long as the major number always goes up when an
incompatible change occurs. What that option effectively does is:

current = major + medium
revision = micro
age = medium

If you're using Libtool "correctly", adding ABI frequently, and not
breaking ABI very often, you tend to end up with large numbers:
telepathy-glib has just reached current = 70. If we broke ABI in our
next release, libtool would have us jump from libtelepathy-glib.so.0 to
libtelepathy-glib.so.71 without any intermediate "major versions".

Regards,
S


-- 
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/4fab7a91.7040...@debian.org