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 adde
]] 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 manua
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
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 b
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
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
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 request
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
>> ch
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 alrea
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 w
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 und
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/c
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 would
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
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
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 init
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 h
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 no
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 cart
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 i
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:
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.
>
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 re
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 Zin
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
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.
>
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
>
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
> > a
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
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
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:
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
[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 so
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 semantic
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 neve
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
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 ma
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 b
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 o
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
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
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
>> acce
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 t
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
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 th
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
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 us
[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 file
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
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 miss
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
> fro
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:
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:
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.
> >
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 experie
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, e
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 eithe
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 gene
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 strik
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 : Collecti
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 s
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
62 matches
Mail list logo
