Svante Signell dijo [Wed, Dec 05, 2018 at 02:03:19PM +0100]:
> > If we keep merged-/usr as default then we can /recommend/ people to
> > install usrmerge to switch to merged-/usr; reducing the difference
> > between newly-installed and existing setups is a good idea IMHO. I
> > think I filed a rep
On Tue, 2018-12-04 at 21:58 +0100, Ansgar Burchardt wrote:
>
> If we keep merged-/usr as default then we can /recommend/ people to
> install usrmerge to switch to merged-/usr; reducing the difference
> between newly-installed and existing setups is a good idea IMHO. I
> think I filed a report for
On Tue, Dec 04, 2018 at 09:58:09PM +0100, Ansgar Burchardt wrote:
> > We later learned only a part of the archive got rebuilt since the bad
> > debootstrap backport.
> Yes, some packages were not yet rebuilt in testing, but having them
> rebuilt in unstable is enough.
looking at https://tests.repr
Adam Borowski writes:
> On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
>> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
>> confident that for more than 0.3% of the archive something can go wrong
>> when building in non-clean environments.
>
> Your figur
On Tue, Dec 04, 2018 at 07:21:11PM +0100, Adam Borowski wrote:
> Your figure of ~80 packages counts only packages which went through a
> reproducible-builds rebuild. We later learned only a part of the archive
> got rebuilt since the bad debootstrap backport.
wrong, sigh.
--
cheers,
Ho
On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
> Ian Jackson writes:
> > Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> >> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
> >> systems would
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrmerge
Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
> systems would no longer be supported. In this case someone would have
> to write a unusrmerge program to convert systems with merge
"Alexander E. Patrakov" writes:
> Ansgar Burchardt wrote:
>> Making the feature default was discussed years ago which you are surely
>> aware of. It's not mandatory.
>
> Unfortunately I have to disagree here. Merged /usr is already,
> de-facto, mandatory for everyone who installs Debian Testing usi
Ansgar Burchardt wrote:
Making the feature default was discussed years ago which you are surely
aware of. It's not mandatory.
Unfortunately I have to disagree here. Merged /usr is already, de-facto,
mandatory for everyone who installs Debian Testing using the official
netinst CD. The user is
On Dec 03, Adam Borowski wrote:
> unusrmerge would still be still far less work than continuing with 2. Yet I
No "unmerge" program is possible since some symlinks are created by
maintainer scripts and hence cannot be recreated except by running again
the maintainer scripts in the right conditi
Adam Borowski writes:
> On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote:
> I believe the difference between those is less than between suboptions of 1
> and 3, but then, as an opponent of 2 as a whole I'm biased.
>
>> Switching to (1) or (3a-with-no-support-in-buster) will mean mer
On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote:
> Gunnar Wolf writes:
> > Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
> >> (...)
> >> So, let's enumerate possible outcomes:
> >>
> >> 1. no usrmerge
> >> 1a. no moves at all (no effort needed!)
> >> 1b. moves vi
Gunnar Wolf writes:
> Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
>> (...)
>> So, let's enumerate possible outcomes:
>>
>> 1. no usrmerge
>> 1a. no moves at all (no effort needed!)
>> 1b. moves via some dh_usrmove tool, until /bin is empty
>> 2. supporting both merged-usr and u
Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
> (...)
> So, let's enumerate possible outcomes:
>
> 1. no usrmerge
> 1a. no moves at all (no effort needed!)
> 1b. moves via some dh_usrmove tool, until /bin is empty
> 2. supporting both merged-usr and unmerged-usr
> 3. mandatory us
On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let'
Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> It is very demotivating to have discussed and implemented something
> mostly years ago, for people then to come and complain "let's not do
> this at all" years later.
We were told it would be opt
Adam Borowski writes:
> I see that we're debating the merits of merged-usr vs non-merged-usr, while
> expending lots of effort and filing bugs (requiring further urgent action of
> unrelated maintainers), for little gain.
There is no "urgent action" required (unlike, say, for the last glibc
update
I see that we're debating the merits of merged-usr vs non-merged-usr, while
expending lots of effort and filing bugs (requiring further urgent action of
unrelated maintainers), for little gain.
In the above, note that the debate vs effort touch different problems:
1. is usrmerge good?
vs
2. how t
19 matches
Mail list logo
