> "Daniel" == Daniel Markstedt writes:
Daniel> Hi all, I have drafted a release of the netatalk package
Daniel> that addresses 5 critical deb bugs. However, I myself am
Daniel> only an uploader in name and don't yet have actual upload
Daniel> privileges. And my
> "Richard" == Richard Lewis writes:
Richard> Otto Kekäläinen writes:
>> Could you point me to some Debian Bug # or otherwise share
>> examples of cases when a build succeeded locally but failed on
>> official Debian builders due to something that is specific for
>>
> "Helmut" == Helmut Grohne writes:
Helmut> In this work, limitations with --chroot-mode=unshare became
Helmut> apparent and that lead to Johannes, Jochen and me sitting
Helmut> down in Berlin pondering ideas on how to improve the
Helmut> situation. That is a longer story,
> "Otto" == Otto Kekäläinen writes:
Otto> Would you be kind and try to understand the opposing viewpoint
Otto> by trying it for one day?
Otto> You could go to
Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
Otto> and conduct a code review?
I have
> "Luca" == Luca Boccassi writes:
Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis
Luca> wrote:
>>
>> Luca Boccassi writes:
>>
>> > Hence, I am not really looking for philosophical discussions or
>> lists > of personal preferences or hypotheticals, but for
> "Johannes" == Johannes Schauer Marin Rodrigues writes:
>> > > If [files can be deleted automatically while mmdebstrap is using
them],
>> > > how should applications guard against that from
>> > > happening?
>> >
>> > As documented in tmpfiles.d(5), if mmdebstrap takes
> "Chris" == Chris Hofstaedtler writes:
Chris> Fellow Developers,
Chris> you are probably aware of the time_t-64bit migration :-)
Chris> However, this does not magically transition all data formats to 64bit
Chris> times. One such instance is the set of utmp/wtmp and lastlog
> "Niels" == Niels Thykier writes:
Niels> # The proposal
Niels> I think our package helper tooling should just automatically
Niels> aggregate all provided substvars of the format ${*:Depends}
Niels> and append it the Depends field. Rinse and repeat for other
Niels>
> "Helmut" == Helmut Grohne writes:
Helmut> pam seems difficult: | extern time_t
Helmut> pam_misc_conv_warn_time; /* time that we should warn user */
Helmut> | extern time_t pam_misc_conv_die_time; /* cut-off time for
Helmut> input */
Helmut> We cannot symbol-version
> "Stan" == Stan Johnson writes:
Stan> sysvinit-core. But if wdm really does require systemd now,
Stan> that might explain this issue, with other X packages being
Stan> dependent on either wdm or systemd. As I recall, wdm is the
It does not look like wdm requires systemd.
I set
There are a number of changes, and I'd just like a bit more confidence
that it works as expected before uploading to unstable in about a week.
Changes include:
* Running pam_umask with usergroups support by default.
* libpam-modules now depends on libsystemd0 because utmp is not
y2038-clean
> "Simon" == Simon Josefsson writes:
Simon> Right, these are slightly different technical problems, but
Simon> as far as the brief discussion in the release notes --
Simon>
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking
> "Steve" == Steve Langasek writes:
>> At one level, krb5-multidev only has an rdep of 5, but I suspect
>> the rdep count for libkrb5-dev is somewhat larger:-) I don't know
>> how many packages would be removed from the transition if we
>> decide most of the krb5 libraries do
> "Steve" == Steve Langasek writes:
Steve> - In multi-library packages, there is no reliable way to map
Steve> from a set of headers in a dev package to specific shared
Steve> libraries in a runtime library package that's not
Steve> additionally computationally prohibitive;
> "Mo" == Mo Zhou writes:
Mo> On 1/5/24 11:45, Ansgar wrote:
>> Then the package should be in main.
>>
>> We do not require external software to be free as well, be that
>> Web APIs provided by Github, Twitter, or the NVidia firmware
>> required for Nouveau,
> "Paul" == Paul Wise writes:
Paul> Hi all, I have noticed that almost all Rust packages in Debian
Paul> have boilerplate long descriptions that aren't very useful to
Paul> Debian users. The only useful info is the crate name, but that
Paul> is also in the package name.
> "Christoph" == Christoph Biedl writes:
Christoph> "cups-bsd | lpr". For lpr, that might be xpaint. For
Christoph> lprng, I have no idea. And there's little chance to know.
For a long time (possibly still) MIT's printing infrastructure required
lprng and I don't think made it easy
> "Josh" == Josh Triplett writes:
Josh> If we're talking about developing a solution that doesn't
Josh> already exist, why not have that solution *be* the
Josh> notification-and-diff/show-the-defaults mechanism you're
Josh> describing? For instance, provide a declarative
>>>>> "Russ" == Russ Allbery writes:
Russ> Sam Hartman writes:
>>>>>>> "Peter" == Peter Pentchev writes:
Peter> Hm, what happens if a sysadmin deliberately removed a file
Peter> that the distribution ships i
>>>>> "Peter" == Peter Pentchev writes:
Peter> On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
>> On Fri, 15 Sept 2023 at 21:08, Sam Hartman wrote:
Peter> Hm, what happens if a sysadmin deliberately removed a file
Peter
> "Luca" == Luca Boccassi writes:
Luca> With the provision that I know next to nothing about pam - if
Luca> I understood correctly how it works, why not simply do both?
Luca> Ship the default file in the package under both /usr and
Luca> /etc. Then, you get the semantics you
Apropos of the discussion about removing default configuration from
/etc.
Upstream PAM now supports doing that. You can set up a vendor directory
such as /usr/lib where pam.d and security live.
I thought about doing that for Debian PAM, and have decided against.
My rationale is that I actually
> "Andres" == Andres Salomon writes:
Andres> Any thoughts on this? Please explicitly Cc me on replies, as
Andres> I'm not subscribed to any of the lists.
Makes sense to me.
> "Roberto" == Roberto C Sánchez writes:
Roberto> sources." I mean, if you're going to wave the code of
Roberto> conduct around (or Andy in the case of the initial report),
Roberto> then perhaps we ought to distinguish between what the code
Roberto> of conduct was very
> "Lucas" == Lucas Nussbaum writes:
Lucas> But unless we go further than that and decide that we don't
Lucas> care at all about 'source builds after successful builds',
Lucas> the bugs (which where filed severity:minor) remain valid.
FWIW in terms of building toward a consensus.
> "Lukas" == Lukas Märdian writes:
Lukas> That would lead to a situation where users would need to
Lukas> differentiate what system they are on when doing their
Lukas> network configuration: Debian Cloud (Netplan)
No, I think if the user is feeding configuration into a cloud
> "nick" == nick black writes:
I consider anything that requires me to write wpa_supplicant config to
be a bad idea (unless I'm running an AP) and NetworkManager driving
wpa_supplicant is a better idea.
--Sam
> "Lukas" == Lukas Märdian writes:
Lukas> Therefore, I'd love to see Netplan to be used in combination
Lukas> with this! It's a clean, declarative configuration language
Lukas> not specifically tied to systemd-networkd as an
Lukas> implementation. So it could also be used
> "Timo" == Timo Röhling writes:
Nod, I was wrong. Wanted to ex plicitly acknowledge that, although I
think it is also obvious from other mails.
Hi.
I have read both of your messages over the weekend multiple times.
I don't think replying point-by-point is going to be all that helpful,
although if there are any cases where you'd like me to do that, I will.
* I am really impressed with the work you are putting in on all this.
You have
>>>>> "Helmut" == Helmut Grohne writes:
Helmut> Hi Sam,
Helmut> On Fri, Jul 07, 2023 at 08:50:49AM -0600, Sam Hartman wrote:
>>
>> TL;DR: It looks like if we do not want to encode merged /usr into
>> the bootstrap pr
> "Bastian" == Bastian Blank writes:
Bastian> On Wed, Jul 05, 2023 at 09:06:24PM -0300, Santiago Ruano Rincón
wrote:
>> For the moment, ifupdown is still installed by the
>> debian-installer as default network interfaces manager. And after
>> sleeping over it, and discussing
>>>>> "Sam" == Sam Hartman writes:
Sam> TL;DR: It looks like if we do not want to encode merged /usr
Sam> into the bootstrap protocol, we must keep some aliases and
Sam> cannot move all files in data.tar. I think removing all
Sam> ali
TL;DR:
It looks like if we do not want to encode merged /usr into the bootstrap
protocol, we must keep some aliases and cannot move all files in
data.tar.
I think removing all aliasing is important and so I am firmly in the
camp of doing usrmerge in the bootstrap protocol.
> "Helmut" ==
> "Helmut" == Helmut Grohne writes:
Helmut> I concur. Given Simon's analysis and the replies even when
Helmut> combined with earlier messages, I now see significantly more
Helmut> voices for the opinion:
Helmut> i386 primarily exists for running legacy binaries and
> "Russ" == Russ Allbery writes:
Russ> Helmut Grohne writes:
Russ> What Sam is trying to
Russ> say, I think, is that a different phrasing offers a way to
Russ> avoid that discussion and agree to disagree on the best
Russ> architecture in the abstract by pointing out an
> "Helmut" == Helmut Grohne writes:
I believe I'm up on this discussion to at least comment on the consensus
calls you discuss in the mail.
Except where noted below, I support your reading of consensus.
Helmut> Consensus proposal #1:
Helmut> This updated DEP17 is a complete
> "Simon" == Simon Richter writes:
>> It also seems a bit strange to require more from the maintainer
>> when they are dropping an init script than we would if a
>> maintainer started depending on a feature like socket activation
>> such that their packkage simply would not
> "Russ" == Russ Allbery writes:
Russ> I think the open question is whether we're happy to just break
Russ> init scripts in unstable, since that migration path means
Russ> there will always be a window where a fully-upgraded unstable
Russ> system has no init script for a
> "Helmut" == Helmut Grohne writes:
Helmut> Moving on to category 4 feels rather obvious, especially
Helmut> because work has been done there in debootstrap. The
Helmut> approach in debootstrap however is one that I see as a dead
Helmut> end, because it causes us to maintain
> "Helmut" == Helmut Grohne writes:
Helmut> I think at this point, we have quite universal consensus
Helmut> about the goal of moving files to their canonical location
Helmut> (i.e. from / to /usr) as a solution to the aliasing problems
Helmut> while we do not have consensus
We've all been talking about the x86_64 ABI, and I'm realizing I'm never
read it.
Are we talking about
https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf
--Sam
> "Helmut" == Helmut Grohne writes:
Helmut> Hi Luca,
Helmut> On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
>> The local/external aspect is already covered in Ansgar's reply
>> and subthread.
Helmut> I hope that we can at least agree that we don't have
> "Helmut" == Helmut Grohne writes:
Helmut> Luca Boccassi kindly pointed me at config-package-dev
Helmut> though. This is a tool for generating local packages and it
Helmut> also employs dpkg-divert. There is a significant risk of
Helmut> breaking this use case. If we were
> "Simon" == Simon McVittie writes:
Simon> You might reasonably say that "the maintainer of bar didn't
Simon> add the correct Breaks/Replaces on foo" is a RC bug in bar -
Simon> and it is! - but judging by the number of "missing
Simon> Breaks/Replaces" bug reports that have
> "Ivan" == Ivan Shmakov writes:
>> Having a bunch of problem reports that no one is interested in
>> cluttering up package pages has a cost. Just for the same
>> reasons you don't want these reports cluttering up your bugs from
>> page, I perhaps don't want them cluttering
> "Gioele" == Gioele Barabucci writes:
Gioele> For example I have opened bugs years ago against packages
Gioele> that I do not use anymore. These reports are still valid and
Gioele> sometime others comment on them, but I would no longer be
Gioele> able to, for example,
> "Steve" == Steve Langasek writes:
Steve> If this is for people doing out-of-archive builds who don't
Steve> want to deal with failures from -Werror, I can see how having
Steve> a single environment toggle is useful to them; but it doesn't
Steve> seem useful to *Debian* when
Helmut> The problem here specifically arises, because we do not have
Helmut> consensus on -Werror being a bad idea in release builds.
I agree with your reading of consensus and for that reason support
registering an option to say do not use -Werror.
> "Antonio" == Antonio Terceiro writes:
Antonio> On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote:
>>
>> On 2/21/23 15:03, Ryan Kavanagh wrote:
>> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
>> > > Description : A tool for glamourous
> "Peter" == Peter Pentchev writes:
Peter> 3. Now, what about the `Files: debian/*` section of the
Peter> debian/copyright file? The common wisdom seems to be that, if
Peter> only to make it easier to submit patches to the upstream
Peter> project, the debian/* files ought to
> "Peter" == Peter Pentchev writes:
Peter> Hi, So I've seen this idea floating around in the past couple
Peter> of years (and in some places even earlier), but I started
Peter> doing it for the couple of pieces of software that I am
Peter> upstream for after reading Daniel
> "Fabian" == Fabian Grünbichler writes:
Fabian> All in all it seems to me like the problem currently is more
Fabian> a theoretical one - it doesn't seem to cause (much, if at
Fabian> all) additional breakage on top of stuff that is already not
Fabian> cross compilable at the
> "Fabian" == Fabian Grünbichler writes:
Fabian> On Wed, Feb 15, 2023, at 7:51 PM, Fabian Grünbichler wrote:
>> Hi,
>>
>> I'm writing this mail in order to get further input from
>> knowledgeable, but not directly involved DDs - mostly those
>> involved with
> "Johannes" == Johannes Schauer Marin Rodrigues writes:
Johannes> This will of course just paper over the issue without
Johannes> fixing the underlying cause. It's what I called "not a
Johannes> good idea" in my last mail.
I like the explicit chgrp style because it explicitly
> "Tomas" == Tomas Pospisek writes:
Tomas> All that said, I have never received negative feedback to
Tomas> these bug triages that I am occassionaly doing and am under
Tomas> the impression that the maintainers *do* appreciate someone
Tomas> going over their packages bugs
> "Santiago" == Santiago Vila writes:
Santiago> El 28/1/23 a las 20:44, Sebastian Ramacher escribió:
>> On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote:
>>> On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
... * Those bugs are RC by definition and have
> "Nilesh" == Nilesh Patra writes:
Nilesh> Since I had done quite a bit of work on this, I'm a sad to
Nilesh> see this happen, as fasttrack still has much less visibility
Nilesh> / availability than an official stable release, or even
Nilesh> backports.
Well, if you and a
> "nick" == nick black writes:
nick> it's 2023 and imho time to stop supporting unshadowed
nick> passwords from the installer.
Yes, absolutely.
I am familiar with nis/PAM/shadow/LDAP, have deployed NIS (although not
nisplus), and have been around long enough to understand the
> "Andreas" == Andreas Metzler writes:
Andreas> Afaiui Graham's *question* was in response to Bastian's
Andreas> "However, please describe an actionable plan." Obviously it
Andreas> would be a lot easier if we could require to have all NEW
Andreas> uploads go to experimental
> "Graham" == Graham Inggs writes:
Graham> Hi All
Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank wrote:
Graham> Would it be a bad thing to require all uploads that need to
Graham> go through NEW (source and binary) to target experimental?
Graham> I have been doing
>I wrote too early sry. A desktop app is also possible. I will use qt.
>Thanks for your time.
QT accessibility has improved a lot, but I suspect that a single page
web app with vuejs and a good widget set on top of that is going to be
more accessible than a QT app even today.
I find I stumble
> "Huỳnh" == Huỳnh Thành Hưng writes:
Huỳnh> Hi all, Special thanks to all of you, your replies really
Huỳnh> help me to know what I need to do. Weekly build image will
Huỳnh> help me reach to the target sooner than "Bookworm version".
Let us clarify a bit.
Our hope is that you
> "Reuben" == Reuben Thomas writes:
Reuben> I am a bit torn here: with my DM hat on, stripping out
Reuben> gnulib sources where possible and using Debian's gnulib
Reuben> package seems the right thing to do. With my upstream hat
Reuben> on it leads potentially to bug reports
> "Otto" == Otto Kekäläinen writes:
Otto> Instead of manually trying to manage TMPDIR env variable in
Otto> various places, we should have a standardized way to run
Otto> maintainer scripts in clean shell sessions that have all env
Otto> variables set automatically correctly.
> "Stephan" == Stephan Lachnit writes:
Stephan> On Mon, Oct 17, 2022 at 11:57 AM Bastian Blank
wrote:
>>
>> Everyone coming up with solutions, please review the old thread
>> about that
>>
https://lists.debian.org/msgid-search/20200405184610.ga581...@waldi.eu.org
> "Steve" == Steve McIntyre writes:
Steve> Hi all! [ I've also blogged about this - see
Steve> https://blog.einval.com/2022/10/02#firmware-vote-result ]
Steve> I'm assuming that there will be no surprises and Kurt will
Steve> shortly confirm the result that devotee reported
> "Dylan" == Dylan Aïssi writes:
Dylan> We cannot talk about PipeWire without mentioning its session
Dylan> manager. Thus, this change should go along the switch of the
Dylan> default session manager, i.e. from the deprecated
Dylan> pipewire-media-session to WirePlumber. We
> "Simon" == Simon McVittie writes:
Simon> I don't think building from the least-derived form is always
Simon> the right thing to do. For instance, take rust-glib-sys, a
Simon> package of Rust bindings for the GLib library, which is one
Simon> of the libraries whose handling
> "Andrey" == Andrey Rahmatullin writes:
Andrey> More sensible than not filing it? This defeats both
Andrey> purposes of an ITP: getting it discussed and working as a
Andrey> mutex for people who are thinking about packaging the same
Andrey> software. Are there other
> "Guillem" == Guillem Jover writes:
Guillem> Hi! There's been talk about switching away from
Guillem> netkit-telnet and netkit-telnetd as the default
Guillem> implementations for some time now, and replacing them with
Guillem> the ones from inetutils, which is a maintained
> "Stephan" == Stephan Verbücheln writes:
Stephan> As far as I understand it, the main point of BabaSSL is to
Stephan> add support for Chinese developed ciphers and algorithms.
It looked like there were two main points.
The first was in fact these ciphers.
I don't think that's a
>>>>> "Vincent" == Vincent Bernat writes:
Vincent> ❦ 10 May 2022 14:30 -06, Sam Hartman:
>> 2) We value being able to build from source when we can. We value
>> being able to have reproducible builds when we can. We don't want
>>
TL;DR: I tried to think about what all would go in non-free-firmware if
we create it.
I think there are some complicated questions especially around source
dvds and dependencies.
Hi. So it sounds like a number of the options involve creating a
non-free-firmware component, and we might even have
> "Russ" == Russ Allbery writes:
Russ> I agree with this option split, but that reminds me of a
Russ> different procedural note.
Russ> While I recognize and respect the desire to create a
Russ> comprehensive ballot, I'm still going to advocate for
Russ> proposing a GR
>>>>> "Marc" == Marc Haber writes:
Marc> On Tue, 19 Apr 2022 08:21:10 -0600, Sam Hartman
Marc>
Marc> wrote:
>> One valuable suggestion was to make sure users could easily
>> select freedom if that's what they wanted. So I think
Steve> 3. We could stop pretending that the non-free images are
Steve> unofficial, and maybe move them alongside the normal free
Steve> images so they're published together. This would make them
Steve> easier to find for people that need them, but is likely to
Steve> cause
> "Marc" == Marc Haber writes:
>> But I'd ask you to look into the history of usergroups in Debian
>> as part of your decision process.
Marc> Where would I read up on that? I am not deeply enough in those
Marc> political things to be able to judge whether a discussion from
>>>>> "Guillem" == Guillem Jover writes:
Guillem> On Thu, 2022-03-10 at 12:09:14 -0700, Sam Hartman wrote:
>> You're trying to produce packages from CI builds or other
>> automation where you sometimes have native Debian revisions.
>&g
> "Steve" == Steve McIntyre writes:
Steve> Ian Jackson wrote:
>>
>> 1. Why is 1.0-without-diff not always worse than 3.0 (native) ?
>>
>> 1.0 native is sometimes better than 3.0 (native) because
>> dpkg-source refuses to build a 3.0 native package with a Debian
> "Marc" == Marc Haber writes:
Marc> Hi, you might have noticed that the adduser package has gained
Marc> I have some issues that I would like to solicit the opinion of
Marc> my fellow DDs and to reach rough consensus about some changes
Marc> that have been requested from
> "Andrey" == Andrey Rahmatullin writes:
Andrey> On Wed, Feb 09, 2022 at 06:53:49PM +0100, Enrico Zini wrote:
>> > > I've added "We should have a default standard packaging
>> workflow": > >
>> https://salsa.debian.org/debian/grow-your-ideas/-/issues/24 >
>> This should
> "Holger" == Holger Levsen writes:
Holger> So what do you all think?
Holger> I'm leaning towards explaining the basics in devref (mostly
Holger> by copying bits from the wiki page) and adding a pointer to
Holger> the wiki page, but if there's consensus that the wiki page
> "Jonas" == Jonas Smedegaard writes:
Jonas> Please note, however, that license _grants_ (i.e. the various
Jonas> ways a copyright holder can state that they grant some
Jonas> _referenced-by-them_ license) need not be included verbatim.
I suspect we're in agreement. But for
> "Zack" == Zack Weinberg writes:
Zack> Maybe it was not obvious to anyone in 2016 that the package
Zack> database being inconsistent with the filesystem could cause
Zack> actual data loss. However, I think it was the responsibility
Zack> of the developers of usrmerge to find
>>>>> "Michael" == Michael Biebl writes:
Michael> Am 17.11.2021 um 19:57 schrieb Sam Hartman:
Michael> AIUI simply moving files from / to /usr within the same
Michael> package is not problematic.
Sorry, I was being overly simplistic.
I think your un
> "Marco" == Marco d'Itri writes:
Marco> On Nov 18, Zack Weinberg wrote:
>> Are you seriously claiming that that phenomenon is not a
>> severity:critical bug?
Marco> I am seriously claming that whatever you are referring to, if
Marco> true, is such a contrived example
>>>>> "Zack" == Zack Weinberg writes:
Zack> On Wed, Nov 17, 2021, at 1:37 PM, Sam Hartman wrote:
>>>>>>> "Zack" == Zack Weinberg writes:
Zack> Therefore: either someone fixes the bug, or the transition
Zack> will h
>>>>> "Marco" == Marco d'Itri writes:
Marco> On Nov 10, Sam Hartman wrote:
>> I'm sorry, but I think the only way in which that horse is dead
>> is that no one has proposed patches to dpkg.
Marco> Indeed, because the sides of this arg
> "Zack" == Zack Weinberg writes:
Zack> The existence of the bug is not in question. A step-by-step
Zack> reproduction recipe was posted in the previous thread. Losing
Zack> files from Essential packages when they are upgraded is
Zack> severity:critical
Agreed so far.
> "Andrej" == Andrej Shadura writes:
Andrej> Hi all, Yesterday I uploaded dash with LINENO feature
Andrej> switched on again, which has the side effect of exposing
Andrej> bashisms in configure scripts. Previously, they were
Andrej> obscured by the fact that autoconf requires
> "Marco" == Marco d'Itri writes:
Marco> On Nov 08, Simon Richter wrote:
>> Yes, but the conversion needs to be performed by dpkg, because
>> the usrmerge
Marco> Please kindly stop beating this long-dead horse.
I'm sorry, but I think the only way in which that horse is dead
Simon> However, the problem with freezing testing but not freezing
Simon> unstable is that if you do that, all updates to testing
Simon> during the freeze (to fix the release-critical bugs that stop
Simon> it from already being ready for release) have to go into
Simon> testing
> "Niels" == Niels Thykier writes:
Niels> If the project consensus of this discussion is aligned with
Niels> the belief that we should block decentralized volunteer work
Niels> on the transition, I will respect the decision.
I was really frustrated reading that, and I hope that
> "Timo" == Timo Röhling writes:
Timo> However, Guillem also seems to think that dpkg can manage file
Timo> symlinks in a real directory better than an directory symlinks
Timo> in /, which is why he proposed symlink farms in the first
Timo> place. Assuming dpkg implements the
> "Simon" == Simon Richter writes:
Simon> Hi,
Simon> On 8/16/21 3:18 AM, Paul Wise wrote:
>> I'd like to suggest that we standardise on the upstream VCS for
>> our orig.tar.gz files and phase out use of upstream packaging
>> ecosystems.
Simon> This is also an
> "Niels" == Niels Thykier writes:
Niels> As I understand it, the issue does not depend on whether
Niels> "usrmerge" is run before or after installing the "/lib"
Niels> version of "foo". On that assumption, running "usrmerge" as
Niels> a part of the upgrade and "cleaning up"
TL;DR: Should we hold off on moving stuff from / to /usr in packages
until we develop our plan?
If so, how do we communicate that to people?
> "Russ" == Russ Allbery writes:
Russ> Simon Richter writes:
>> It is less nonsensical because usrmerge exists, since we
>> presumably
> "Simon" == Simon Richter writes:
>> I can see two arguments why we might need a dpkg update:
>>
>> 1) To fix bugs related to directory aliasing.
>>
>> I don't think that there is a consensus those bugs need to be
>> fixed to move forward. (Put another way it's
> "Simon" == Simon Richter writes:
Simon> Current dpkg already has handling code so that /bin/foo ->
Simon> /usr/bin/foo is not a problematic move even on usrmerge'd
Simon> systems, so a possible policy would be to allow those and
Simon> disallow package splits, that way we
1 - 100 of 717 matches
Mail list logo
