On Sun, Apr 20, 2025 at 10:56:49PM +0300, Adrian Bunk wrote:
> On Sun, Apr 20, 2025 at 06:25:53PM +0100, Josh Triplett wrote:
> > On Sun, Apr 20, 2025 at 02:56:58PM +0300, Adrian Bunk wrote:
> > > On Thu, Apr 17, 2025 at 01:38:18PM -0700, Josh Triplett wrote:
> > &
G. Branden Robinson wrote:
> At 2025-04-20T23:22:04+0500, Andrey Rakhmatullin wrote:
> > On Sun, Apr 20, 2025 at 06:25:53PM +0100, Josh Triplett wrote:
> > > What I'm suggesting here is that if every individual package that
> > > needs awk has a Depends on it (via
Michael Lazin wrote:
> I think removing awk is a bad idea. It will break legacy scripts as
> has already been suggested. I am mostly an observer on this list and
> say very little but I think that awk is used by a lot of people. I
> used it in a script that analyzed mail logs for example. It wa
On Sun, Apr 20, 2025 at 10:12:24PM +0300, Adrian Bunk wrote:
> Container size is obviously not a priority for such users.
That is incorrect. Many, many users use Debian as the basis for
containers, and many such users care about container size, sufficiently
so to work on reducing it. You are sugge
Andrey Rakhmatullin wrote:
> Should we start declaring deps on all essential packages explicitly?
I personally think that would be a good idea, though I'm not currently
trying to make the case for that across the board here. Right now, I'm
trying to make the case that that's a good first step for
On Sun, Apr 20, 2025 at 08:58:29PM +0300, Adrian Bunk wrote:
> On Sun, Apr 20, 2025 at 06:05:13PM +0100, Josh Triplett wrote:
> > On Sun, Apr 20, 2025 at 12:48:08PM +0200, Simon Josefsson wrote:
> > > Josh Triplett writes:
> > >
> > > > And the extra sym
On Sun, Apr 20, 2025 at 02:56:58PM +0300, Adrian Bunk wrote:
> On Thu, Apr 17, 2025 at 01:38:18PM -0700, Josh Triplett wrote:
> > Simon Josefsson wrote:
> > > Debian trixie images ship with 'mawk' pre-installed right now. While
> > > I'm not convinced the
On Sun, Apr 20, 2025 at 12:48:08PM +0200, Simon Josefsson wrote:
> Josh Triplett writes:
>
> > And the extra symlinks in `/etc/alternatives` don't take much size; I
> > agree you don't need update-alternatives, but then, you also don't
> > strictly ne
Michael Stone wrote:
> Debian is a general purpose OS that can form the foundation for a lot
> of variants. But, that flexibility has a cost, and the cost is size &
> complexity. /var/lib/apt and /var/lib/dpkg alone are the size of a
> minimal linux distribution, without even accounting for actual
to consider avoiding
it in *some* especially valuable cases, and conversely would allow folks
building container/VM/embedded images to know when they actually need
it.
In general, I think this is roughly the right approach for any proposed
work on the Essential set, with the first step being to declare
dependencies explicitly.
- Josh Triplett
On Mon, Dec 23, 2024 at 08:23:33AM -0500, Theodore Ts'o wrote:
> On Sat, Dec 21, 2024 at 04:38:46PM -0800, Josh Triplett wrote:
> > On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
> > > > Right now, the model we have is "some packages use the empty /etc model
On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
>
>
> > Right now, the model we have is "some packages use the empty /etc model,
> > some packages install commented-out defaults, and there's no
> > consistency". I'd love to move to the model of "all packages use
> > whichever model the sysa
Russ Allbery wrote:
> And this is the root of the problem: you want one thing for understandable
> reasons, and other people, like myself, would prefer the opposite behavior
> of having /etc empty by default for different understandable reasons. We
> both understand the other's point of view and si
On Fri, Dec 20, 2024 at 09:55:17AM +0100, Samuel Thibault wrote:
> Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> > Samuel Thibault wrote:
> > > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > > And it is actively harmful as if one edit
Samuel Thibault wrote:
> Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > And it is actively harmful as if one edits the example configuration to
> > have a useful configuration as dpkg will start annoying admins with
> > "the example configuration has changed; what do you want to do"
>
Marc Haber wrote:
> don't take the old version away until the new one is feature par and
> bug free.
Leaving aside the points Philipp Kern made (some features are
intentionally removed, and code is rarely if ever "bug free")...
Another way of phrasing "don't take the old version away" is "someone
Mike Hommey wrote:
> On Thu, Dec 05, 2024 at 01:02:29PM -0800, Josh Triplett wrote:
> > In the future, if users can easily filter out locale data, we could
> > decide that that's the easier path to support such users, and that fewer
> > package maintainers need to mainta
Theodore Ts'o wrote:
> I'd like to hear from people who manage container
> images. They were the ones whose complaints led to the separation of
> how e2fsprogs-l10n from e2fsprogs in the first place
How many containers need to have e2fsprogs installed at all?
My container images just don't inc
Theodore Ts'o wrote:
> On Thu, Dec 05, 2024 at 01:02:29PM -0800, Josh Triplett wrote:
>> https://bugs.debian.org/1089110
>
> I've looked at this bug, but unlessed I missed something, this seems
> to be "rm -rf /usr/share/locale" shouldn't cause binarie
On Thu, Dec 05, 2024 at 01:28:11PM -0500, Theodore Ts'o wrote:
> On Thu, Dec 05, 2024 at 09:28:34AM -0800, Josh Triplett wrote:
> > There are a variety of reasons people don't want a package installed.
> > For packages that run a service or affects how the system behaves
ns can use things like dpkg
exclusions to omit all of /usr/share/locale when building tiny images.
That might reduce the pressure on packagers to split out -l10n-
packages.
- Josh Triplett
On Sun, Sep 22, 2024 at 10:30:12PM +0200, Andrea Pappacoda wrote:
> On Sun Sep 22, 2024 at 8:06 PM CEST, Josh Triplett wrote:
> > There's one other desirable feature that would make this a robust
> > solution: having NetworkManager do something to handle or ignore
>
Simon McVittie wrote:
> On Sun, 22 Sep 2024 at 12:22:50 +0200, Chris Hofstaedtler wrote:
> > d-i could make (or offer) a choice between networkd and
> > NetworkManager.
>
> d-i *already* makes a choice between ifupdown and NetworkManager: if
> NM has been pulled in by a task's dependencies (e.g. th
Bill Allombert wrote:
> Dear Debian developpers,
>
> I ma looking for a wrapper around the various compressions programs
> (gzip, bzip2, xz, zstd, etc.)
> that would provide the same interface as zcat but would automatically
> pick the right decompressor.
>
> I could easily write one but it probabl
sense for the installer to treat them as effectively mutually
exclusive so that the user's installed system ends up with at most one
of them.
- Josh Triplett
Barak A. Pearlmutter wrote:
> You know, that's a pretty good idea!
>
> Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly states the
> default deletion policy, the policy in place if it's not the default,
> and a pointer to info about altering it. "/tmp's contents are deleted
> at boot whi
Michael Biebl wrote:
> - CAP_SYS_ADMIN: exceed /proc/sys/fs/file-max, the system-wide limit
> on the number of open files, in system calls that open files (e.g.
> accept execve), use of setns(),...
I realize that you can't lock down things upstream still requires, but
CAP_SYS_ADMIN is root-equival
y.
Perhaps we could get consensus around the idea that people want the
ability to make this choice, and packages should integrate with such a
mechanism rather than choosing on a package-by-package basis?
- Josh Triplett
Simon McVittie wrote:
> For example, dbus-daemon can only usefully have hardening applied if it
> was built with traditional (non-systemd) service activation disabled,
> which we cannot usefully do in Debian for two reasons: because we support
> non-systemd init systems, and because we don't (curre
Russ Allbery wrote:
> This is more of a high-level design intuition that stems from some basic
> architectural principles, such as "dpkg should be the authority for what
> Debian installs on the file system so that it can ensure global
> consistency."
>
> But to give you a concrete answer, here ar
o be making *any* changes to the
installer, let alone changes that require translations. Also, if we
already have some detection like that, my apologies for missing it.)
- Josh Triplett
Ansgar wrote:
> could we drop the Priority field from most packages? Most packages use
> "Priority: optional" and this is just noise in d/control (source
> package). Tools should just assume "optional" when no other value is
> set.
This seems like a great idea. People regularly note the overhead o
because we've patched our gzip to parse it"
The x86-64 ABI is set. Feel free to make the case to the next
architecture designer that their new ABI should have the dynamic linker
in `/usr/lib`. That would *not* have the same downsides, as long as
everyone agrees on a path.
- Josh Triplett
Marc Haber wrote:
> On Tue, 14 Feb 2023 11:23:55 -0800, Russ Allbery wrote:
> >I think the right answer (which as is often the case involves a lot more
> >work) is to break the configuration file into separate parts, one of which
> >is a true configuration file in the Policy definition and the oth
allow
creating UID namespaces as non-root.
As a bonus, testsuites could use an overlayfs instead of a read-only
bind mount, and then check afterwards if *any* changes occurred in the
overlay, which would be a test failure.
Does that seem like a reasonable addition to the DPKG_ROOT support?
- Josh Triplett
Matt Barry wrote:
> On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote:
> > On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote:
> > > Anyway, its been released at this point, so the issue is moot :)
> >
> > Regardless of the rest of the discussion, this isn't entirely true.
> > Yes, peop
Michael Biebl wrote:
> I'd agree here. user crontabs are such a niche case where systemd's
> own facilities don't provide a direct replacement.
>
> That said, my main point was about packages shipping cron files.
>
> As a distro we'd benefit if those shipped native systemd timers
> (instead or in a
Thomas Goirand wrote:
> On 9/10/21 10:53 AM, Josh Triplett wrote:
> > Thomas Goirand wrote:
> >> On 9/8/21 6:01 PM, Josh Triplett wrote:
> >>> Now, that said, if the build process actually wants a DNS server to
> >>> run tests against, it should provide
Thomas Goirand wrote:
> On 9/8/21 6:01 PM, Josh Triplett wrote:
> > Now, that said, if the build process actually wants a DNS server to
> > run tests against, it should provide or depend on such a DNS server,
> > and configure it for such tests.
>
> Just to be 100%
inst, it should provide or depend on such a DNS server, and configure it for
such tests. But a build process that's just *importing the dnspython library*
should not need to have either /etc/resolv.conf *or* a functional DNS server.
- Josh Triplett
finitely isn't a "vendor", and the OS shouldn't be "none"
since there is an OS of sorts.
For that reason, Rust uses the target names "aarch64-unknown-uefi",
"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
right names for these targets in other toolchains, as well.
- Josh Triplett
Helmut Grohne wrote:
> So you made me thinking, can we somehow implement this with our
> current spec? The most important requirements seem to be:
>
> * libsystemd-shared.so and /sbin/systemd need to reside in the same
>binary package.
> * It shall be possible to depend on libsystemd-shared.s
Steinar H. Gunderson wrote:
> On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> > locate is a purely user-facing tool,
> > not really usable for portable scripting, since neither its presence nor
> > its functioning can be assumed.
>
> Really? Basi
l and use it, but we shouldn't make all users pay the cost
of locate's database update to satisfy the subset of users who ever
invoke locate.
- Josh Triplett
On Tue, Dec 29, 2020 at 03:19:30PM +0200, Adrian Bunk wrote:
> [...] Rust [...]
I did not bring up Rust, nor was I referring to Rust specifically, nor
am I speaking for either Rust upstream or the work of the Rust team in
Debian. There are *multiple* ecosystems in which the equivalent of
shared-li
Package: libpam-modules
Version: 1.4.0-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org, debian-devel@lists.debian.org
The new pam 1.4.0 has switched pam_unix from libnsl.so.1 (in libc6) to
libnsl2 and libtirpc3, which brings those packages into the
pseudo-Essential set. This is a rather sub
Simon McVittie wrote:
> On Sat, 26 Dec 2020 at 14:55:17 -0800, Josh Triplett wrote:
> > I'm talking about packaging xyz 1.3.1 and 2.0.1, as separate xyz-1 and
> > xyz-2 packages, and allowing the use of both in build dependencies.
>
> This is not all that rare even for
Stig Sandbeck Mathisen wrote:
>>> Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
Since `eog http://example.com/image.png` will open the image,
shouldn't an "open" program ask to the server what the media type
of the URL is, and pass it to the default program able
On Mon, Dec 28, 2020 at 03:20:35PM +0200, Adrian Bunk wrote:
> On Sat, Dec 26, 2020 at 02:55:17PM -0800, Josh Triplett wrote:
> >...
> > If you want to package abc version 1.2.3, and among many other things,
> > abc depends on xyz version 2.1.4, and xyz has a new version 3.
Adrian Bunk wrote:
> On Fri, Dec 18, 2020 at 04:25:19PM -0800, Josh Triplett wrote:
> >...
> > I'm not suggesting there should be 50 versions of a given
> > library in the archive, but allowing 2-4 versions would greatly simplify
> > packaging, and would allow
perhaps if the same maintainer of the
source package lang-modname-5 is uploading a source package for
lang-modname-6, that package can skip NEW.) We can always file RC bugs
on packages in the archive, and even remove packages later.
Given all of the above improvements, it'd be much more feasible for
tooling to help systematically unbundle and package dependencies, and to
help manage and transition those dependencies in the archive.
- Josh Triplett
Roland Fehrenbacher wrote:
> > "S" == Sven Joachim writes:
> S> In addition, the packages in *main*
> S>
> S> * must not require or recommend a package outside of *main* for
> S> compilation or execution (thus, the package must not declare a "Pre-
> S> Depends", "Depen
[Accidentally sent this early before it was finished.]
Roland Fehrenbacher wrote:
> > "S" == Sven Joachim writes:
> S> In addition, the packages in *main*
> S>
> S> * must not require or recommend a package outside of *main* for
> S> compilation or execution (thus, the pack
Ansgar wrote:
> Holger Levsen wrote:
> > On Wed, Sep 09, 2020 at 06:27:28AM +, Francisco Vilmar Cardoso
> > Ruviaro wrote:
> > > * Package name: tty-share
> > > Version : 0.6.2
> > > Upstream Author : Vasile Popescu
> > > * URL : https://github.com/elisescu/tty-shar
tion to keep only N entries maximum
regardless of the above heuristic; that will help packages that have
huge changelogs, or exclusively Debian revisions and no new upstream
version.
Does that sound like a reasonable default?
- Josh Triplett
ramfs, etc.]
This proposal looks great to me! I'm glad that it doesn't remove the
requirement to declare dependencies; that makes it more feasible to
carefully manage such packages without worrying about mysterious
breakage.
I'd love to see several of the packages currently marked Essential move
over to using Protected instead.
- Josh Triplett
Noah Meyerhans wrote:
> Spamassassin has traditionally supplied a cron.daily script. I'd like
> to provide the same functionality via a systemd timer, while still
> providing cron as a fallback. For the most part, this is
> straightforward, but there are a few details on which I'd like feedback.
ettings-daemon 3.34.2-1 were just
uploaded today, adding support for elogind.
I have hopes that Debian's vaunted and venerable development processes
will continue to produce good results, and I hope that the new decade
sees developers healing and recovering from the last.
- Josh Triplett
Russ Allbery wrote:
> Josh Triplett writes:
> > Part of the problem is that the people interested in sysvinit don't tend
> > to care about those features and often argue that others shouldn't care
> > either, and the people interested in those features don't t
Russ Allbery wrote:
> One of the options that I find interesting is to enumerate a list of
> features in unit files that Debian supports, and require that any
> Debian init system be able to handle unit files with those features.
> This standardzes an *API* for both package maintainers and upstream
On Wed, Oct 30, 2019 at 03:30:17PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote:
> > Today, people can't use systemd persistent timers in place of cron (and
> > in place of anacron's "wake up periodically" ap
[Please CC me on replies.]
Simon Richter wrote:
> On Wed, Oct 30, 2019 at 05:14:02AM -0700, Josh Triplett wrote:
> > If we're going to have a GR, part of the goal should be to either
> > confirm the current state that we're never moving very far past the
> > cap
, but we can't use any capabilities that
go substantially beyond sysvinit".
If we're going to have a GR, part of the goal should be to either
confirm the current state that we're never moving very far past the
capabilities of sysvinit even when most people don't run it, or that
we're allowed to use the full capabilities of our default init system
even when there's no equivalent elsewhere.
- Josh Triplett
Jonathan Carter wrote:
> Ah great, having a "/etc/initramfs-tools/conf.d/initramfs-permissions"
> that contains "UMASK=0077" and running "update-initramfs -u" does fix
> that for me locally, I think it should be reasonable to add that to the
> calamares-settings package for Debian.
>
> Does anyone
On Thu, Feb 21, 2019 at 10:26:36PM +0100, Gabor Gombas wrote:
> On Wed, Feb 20, 2019 at 02:44:37PM -0800, Josh Triplett wrote:
>
> > Both syslog and journald support multi-line log messages; I'd *love* to
> > see /var/log/aptitude and /var/log/apt/history.log end up in
On Wed, Feb 20, 2019 at 03:38:41PM -0800, Russ Allbery wrote:
> Josh Triplett writes:
> > Both syslog and journald support multi-line log messages
>
> syslog does not support multi-line log messages in any reasonable way. It
> just escapes the newline (if you're lucky)
On Wed, Feb 20, 2019 at 02:03:08PM -0800, Josh Triplett wrote:
> While there are *absolutely* configurations in which system
> administrators want to log to arbitrary locations and files, I would
> like to propose that for consistency we should configure software to
> unify logging int
On Wed, Feb 20, 2019 at 11:53:24PM +0100, Guillem Jover wrote:
> * The log data is "chroot" specific. This applies to all of the package
> management logs. Logging into syslog would by default not do the right
> thing and would be extremely confusing. I could see adding options
> for dpkg and
On Wed, Feb 20, 2019 at 02:19:02PM -0800, Russ Allbery wrote:
> Josh Triplett writes:
> > While there are *absolutely* configurations in which system
> > administrators want to log to arbitrary locations and files, I would
> > like to propose that for consistency we should
entually, as we configure most applications for this default, we could
introduce this into policy as a "should", but for now I'm seeking
interest in slowly adapting applications to shift defaults to unified
logging.
- Josh Triplett
Tollef Fog Heen wrote:
> ]] Sean Whitton
>
> > There are two cases which we think that everyone would agree that there
> > is a bug, but we are not sure that the bug would be considered to be RC.
> > We are posting to -devel to see if, in fact, we do have a consensus that
> > these bugs would be RC
[Please don't CC me on responses, and please follow up solely to -devel rather
than cross-posting.]
Please note in the following mail that I'm raising this *exclusively* as a
policy and procedures issue, *not* a technical issue. I would request that
people *please* focus on the policy and procedur
Dmitry Bogatov wrote:
> [ I am not subscribed. Please keep me in CC. ]
[I'm assuming that CCing the various init system @packages.debian.org
addresses suffices?]
> Currently, init system packages (sysvinit-core, runit-init,
> systemd-sysv) are mutually exclusive -- each of them provides,
> among
ent it doesn't, which seems questionable) is a bug. And it's
absolutely a feature to have runit scripts and sysvinit scripts and
configuration snippets of many sorts maintained in separate packages.
- Josh Triplett
d also have a dh-style script that automatically moves files and
creates a /usr/usrtransition.d/packagename.conf file read by that
boot-time mechanism. Then we know the transition will be handled
correctly, and we won't have packages getting the details wrong and
ending up with RC bugs.
Sound reasonable? I'd be happy to work on that.
- Josh Triplett
On Tue, Nov 20, 2018 at 09:00:23PM +0100, Samuel Thibault wrote:
> Hello,
>
> Josh Triplett, le lun. 05 nov. 2018 21:02:32 -0800, a ecrit:
> > Speaking with an upstream Rust hat on in addition to a Debian hat:
> > what could Rust do to make life easier for porters?
>
>
On Thu, Nov 08, 2018 at 06:28:29AM +0900, Mike Hommey wrote:
> On Wed, Nov 07, 2018 at 01:21:44PM -0800, Josh Triplett wrote:
> > > I have worked with the Rust upstream sources
> > > well enough to know these issues. You have a regression in Rust 1.25 and
> > >
On Wed, Nov 07, 2018 at 08:47:53PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/7/18 8:07 PM, Josh Triplett wrote:
> >> Well, I wouldn't bet on that. I know that a lot of people have the
> >> feeling that rewriting everything in Rust will solve all problems
> >&g
On Wed, Nov 07, 2018 at 11:53:06AM +0100, John Paul Adrian Glaubitz wrote:
> Hello!
>
> > librsvg has rewritten substantial fractions of its code upstream in
> > Rust. It won't be the last such library or package to do so.
>
> Well, I wouldn't bet on that. I know that a lot of people have the
> f
John Paul Adrian Glaubitz wrote:
> >> Why would I need to communicate that?
> > Because coordination needs involvement from all
>
> If the maintainer of a package doesn't understand which reverse
> dependencies his package has, he shouldn't be the maintainer of
> his package.
This is not a situ
Ian Jackson wrote:
> tl/dr: would this be wrong
>Package: libpam-elogind
>Provides: libpam-systemd
> and should there be a Conflicts too ?
Please don't, no, for multiple reasons.
First, various packages followed the widely offered advice of using
libpam-systemd as the correct package to d
Theodore Y. Ts'o wrote:
> Finally, if I have a systemd timer file, as well as a crontab entry,
> what is the recommended way to decide whether to install/use the
> crontab versus the timer unit file?
Unfortunately, there isn't a clean mechanism for that. For systemd unit files,
systemd's built-in
Wouter Verhelst wrote:
> On Wed, Jan 03, 2018 at 09:13:24AM -0500, Paul R. Tagliamonte wrote:
>> Conversely, if the patches are invasive and unmaintainable, its not on Debian
>> to merge them.
>
> Yes. But adding a "nosystemd" build profile is in no way "invasive and
> unmaintainable".
"nosystemd"
Russ Allbery wrote:
> Josh Triplett writes:
> > Russ Allbery wrote:
>
>>> It does, however, mean that it's a good idea for us to continue to
>>> support sysvinit.
>
>> Not quite. It means we should maintain support for sysvinit *scripts*
>> for
Russ Allbery wrote:
> m...@linux.it (Marco d'Itri) writes:
> > On Dec 31, Simon Richter wrote:
>
> >> These are running stretch, and I would like to upgrade them without
> >> breaking my existing scripts, which assume sysvinit with runlevels
> >> (including one-shot runlevels).
>
> > Somebody ha
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.6.32, BuildID[sha1]=09642c1eb0869e8a9c075d0e8109f7ef1f62b320, with
debug_info, not stripped
- Josh Triplett
Anyone interested in helping with continued support for classic window
managers should consider working on packaging for
https://wiki.archlinux.org/index.php/Xdg-menu , and perhaps forming a
maintenance team for it. And if it doesn't support your window manager
or desktop of choice, consider adding
Scott Kitterman wrote:
> Reintroducing /usr/bin/python as a python3 version risks their systems
> for no benefit (since all python3 stuff points to /usr/bin/python3 and
> works fine). Just let it go and don't bring it back.
Agreed completely. /usr/bin/python -> python3 in Arch is an endless
foun
Adam Borowski wrote:
> Alas, having "bash-completion" installed, while adding some
> context-sensitive completion, also breaks filename completion.
You can always press Alt-/ if you want to use filename completion
unconditionally.
But if you run into a command that accepts filenames but for which
Vincent Danjean wrote:
> Perhaps, Debian can try to standardize this (for future releases), for
> example asking to put the default config files in a central place (with
> symlinks if required), for example /etc/default-config or even
> /lib/default-config and/or /usr/lib/default-config.
We cannot
Adam Borowski wrote:
> On Mon, Apr 24, 2017 at 11:17:48AM +0200, Marco d'Itri wrote:
> > While this scheme was probably instigated by limitations in RPM, at this
> > point we have had multiple packages (kmod, systemd, udev for a start)
> > using it for years.
> >
> > Moving the sysctl.d default
On Sun, Apr 23, 2017 at 09:01:13PM +0200, Evgeni Golov wrote:
> On Sun, Apr 23, 2017 at 11:40:34AM -0700, Josh Triplett wrote:
> > On Sun, Apr 23, 2017 at 08:37:59PM +0200, Evgeni Golov wrote:
> > > On Sun, Apr 23, 2017 at 10:48:33AM -0700, Josh Triplett wrote:
> >
On Sun, Apr 23, 2017 at 08:37:59PM +0200, Evgeni Golov wrote:
> On Sun, Apr 23, 2017 at 10:48:33AM -0700, Josh Triplett wrote:
> > Evgeni Golov wrote:
> > > But this does not account for the fact that this specific tunable may be
> > > already overriden in another sy
Henrique de Moraes Holschuh wrote:
> 1. read current levels (using sysctl, not directly).
>
> 2. if they are above the default, don't change the state of the system:
>if your config file is there, let ucf handle its update normally. if
>your config file is *NOT* there, assume deleted and
n't think you need to worry about that kind of
configuration conflict unless it comes up. Ideally if multiple packages
need to change this limit, they'll coordinate and agree on the new
value, or perhaps even depend on a common configuration package.
- Josh Triplett
Carlos Alberto Lopez Perez wrote:
> On 26/03/17 01:01, Walter Landry wrote:
> > Florian Weimer wrote:
> >>> #5 Declare GMP to be a system library.
> >>>
> >> (snip)
> >>
> >>> #5 was how Fedora looked at the OpenSSL library issue. Since Debian
> >>> has another viewpoint on OpenSSL I somehow doubt
Adam Borowski wrote:
> I'd like to discuss (and then propose to -policy) the following rule:
>
> # Libraries which don't provide a convenient means of conditionally loading
> # at runtime (this includes most libraries for languages such as C), SHOULD
> # NOT declare a "Depends:" or "Recommends:" re
icial" zlib. You can create
your own version, and label it appropriately; the official version
remains the official version. Changing a standards document doesn't
change the standard.
This really comes down to a question of endorsement: we determine
whether a standards document represents the "official" version by
looking at whether it has the endorsement of a particular standards
body.
- Josh Triplett
Mike Hommey wrote:
> Why not just create a ~/.thunderbird symlink to ~/.icedove if
> ~/.icedove exists?
This seems like the right solution. (Or, equivalently, rename
~/.icedove to ~/.thunderbird and place a symlink in the other
direction.)
Any particular reason not to do this?
- Josh Triplett
On Mon, Jan 23, 2017 at 08:56:31PM +0100, Ansgar Burchardt wrote:
> Josh Triplett writes:
> > Given that, can you please go ahead and add the two new sections for
> > rust (https://bugs.debian.org/845576) and javascript
> > (https://bugs.debian.org/753480), and update
1 - 100 of 356 matches
Mail list logo
