Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello Chris, On Mon 28 Mar 2022 at 10:35PM +02, Christoph Berg wrote: > The problem here is that if ul-extra contains things besides rename, > and it conflicts with the perl rename, people will rightfully complain > that they can't install /usr/bin/fincore-from-ul-extra and > /usr/bin/rename-from-perl at the same time. Indeed, and doesn't it violate Policy 10.1, which says "Two different packages must not install programs with different functionality but with the same filenames" ? Perhaps it's an edge case. -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: Native source package format with non-native version
Hello Lucas, Many thanks for providing this summary of your position. Let me just note a point of disagreement: On Tue 15 Mar 2022 at 10:06PM +01, Lucas Nussbaum wrote: > A point that I find important is the following: as a project, I think > that we care about facilitating the review of changes we make to > upstream source. Certainly we do. > I think that the preferred method (and widely accepted method) for > that is currently to use the 3.0 (quilt) format with DEP-3-documented > patches, on top of a tarball that contains the pristine upstream > source. > > The git packaging workflows that generate source packages using either > 1.0 native packages, or 1.0 non-native packages without patches, make it > harder to identify and review those changes, as they require browsing > the git repository, which sometimes is not properly documented using > Vcs-*. I don't think it's the preferred method. I believe most of the project sees git histories are the preferred tool for achieving the goal you state. If we had only source packages for this purpose, then yes, 3.0 (quilt) plus DEP-3 would be preferred. But we have git, too, and indeed dgit. Repositories for packages contain both upstream history and Debian packaging history, and we have powerful git subcommands for extracting information. In many cases there is a good argument to be made that the git history is part of the preferred form of modification. -- Sean Whitton signature.asc Description: PGP signature
Bug#994388: dpkg currently warning about merged-usr systems
On Fri, 25 Mar 2022 18:04:14 + Luca Boccassi wrote: > On Fri, 2022-03-25 at 11:32 -0600, Gunnar Wolf wrote: > > Luca Boccassi dijo [Fri, Mar 25, 2022 at 02:28:12PM +]: > > > I am part of that group, and that is definitely _not_ why I wouldn't > > > touch dpkg with a barge pole as things stand (and have stood for > > > years). You are making a gigantic leap with that assumption, not sure > > > what you base it on. As a downstream and upstream maintainer in several > > > large projects I fix things that don't impact me all the time, all over > > > the place. > > > > > > But anyway, it turns out it's all moot because - drum roll - there is a > > > patch: > > > > > > https://0x0.st/oNFG.diff > > > > > > This was shared just now on #debian-devel IRC by user 'uau', linked > > > here with explicit permission. > > > > > > So it looks like you, Russ and others who chimed in this thread should > > > now be in a position to test your theory that a missing patch was the > > > only issue. Care to take it forward? > > > > Wow, this is a positive turn of events! Do you happen to have more > > information as to the identity of the submitter? We should be able of > > properly granting attribution... > > > > The patch seems sane from a first, very much 1m-point-of-view. Of > > course, it is very situation-specific and not generalized for > > following any unexpected symlinks in the directory hierarchy, but I do > > not expect that to be an issue (as we are talking about a very > > specific migration here). I am absolutely unfamiliar with dpkg > > internals and there are some bits that jump to my eye, but I do not > > think there is much use in me discussing very-minor things that should > > be obvious to people who are actually involved with dpkg. > > > > Has this diff been shared with Guillem, or included in any relevant > > bug report? > > Sorry, I don't know anything more than what I have shared - it was > linked and briefly discussed by user 'uau' on #debian-devel this > afternoon. I just happened to be online, noticed it and asked for > permission to share it here, which was granted. I do not know this > user, and I do not know if this patch has been shared or discussed > elsewhere. The author of the patch today on IRC confirmed that the patch is under the same license as dpkg (GPL2+), and when asked if they plan to push it forward, there was no answer. So the license is clear if somebody else wants to take it forward. Also worth noting that a couple of days ago, the author wrote on #debian-devel that some time ago the patch was presented to the dpkg maintainer, who rejected it with an answer along the lines of the usual "usrmerge is broken by design", with no further comment. So, what is the next step? Will the those on this thread who asserted they think a correct patch would be accepted without issues try and take it forward themselves? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1003653: Revision of removal of rename.ul from package util-linux
Re: Chris Hofstaedtler > > * which binary package should contain the util-linux rename? > >- bsdextrautils > >- something else > > util-linux-extra. Unrelatedly, other non-essential binaries from > util-linux should also move into this package, but this is only > tangentially related. Hi, I like that package name. > > * where should it be installed? > >- /usr/bin > >- something else? > > /usr/bin/rename > > * should there be a Conflicts or Breaks relation with the perl rename? > > I think this will be necessary. The problem here is that if ul-extra contains things besides rename, and it conflicts with the perl rename, people will rightfully complain that they can't install /usr/bin/fincore-from-ul-extra and /usr/bin/rename-from-perl at the same time. Or would you solve that using alternatives, without the conflicts? (Fwiw I believe the strict rule "alternatives only for compatible interfaces" doesn't apply here - we are looking for a workaround, and there is no rule saying that only hacks X, Y, Z must be used for these. If alternatives are the best tool for the job, it should be used.) Christoph
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi Chris, On Mon, Mar 28, 2022 at 07:58:11PM +0200, Chris Hofstaedtler wrote: > I would like to ask a question: under which constitution point will > the CTTE act? Given your reply, I believe that no 6.1.1-4 decision is necessary. The views of the submitter seem sufficiently covered in what you described. I do not think there is a need to codify 6.1.5 advice either. It seems that what happened was mediation. If a resolution is deemed necessary, I'd propose "we decline to overrule the maintainer" with a rationale. We'll likely figure that out on our next meeting in 8 days. On the other hand, I'd like you to commit to including the util-linux rename binary in time for the bookworm release (assuming NEW is processed in a reasonable time). That likely implies that it needs to be uploaded within 2022. Preferrably sooner. Can you confirm that? Helmut
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi Helmut, * Helmut Grohne [220208 21:23]: > Hi Chris, > > On Sun, Jan 23, 2022 at 10:04:34PM +0100, Chris Hofstaedtler wrote: > > I was hoping we could put util-linux' rename into the > > "bsdextrautils" binary package, which has utilities like write, col, > > etc; to avoid putting it into an Essentials: yes package, and to > > avoid a new binary package. However, picking bsdextrautils seems > > ... maybe not ideal if it should Conflict with rename. > > > > I guess the best thing would be to introduce a new binary package, > > but I am out of ideas on naming it. Open for ideas here. > > This paragraph can be vaguely interpreted as an intention to put the > util-linux rename implementation back into some binary package under > some path. Doing so would go a significant way towards what the > submitter of the ctte bug wants. > > We've discussed a number of possible ways to put it back (various > packages, various paths, with or without update-alternatives, with or > without Conflicts). From what you said, I understand that: > * You disagree with putting it in some transitively essential package. > * You think that Debian should make a choice about the rename API and >stick to that. > * You take issue with "rename.ul" as a program name, because it is >inconsistent with other Linux distributions. > * You agree on shipping the util-linux rename executable (with >unspecified filename at this stage) in some Debian binary package in >principle. > > Do you confirm these statements? Yes. I would like to say that my point of view would be "if we change something, lets do the right thing going forward". If we need to break with the past, lets do it now instead of delaying further. > Given these, we think that much of the issue can be resolved > cooperatively. To get there we (as ctte) ask you to explain how you > prefer adding the util-linux rename executable as precisely as you see > it at this stage. > > In your option, > * which binary package should contain the util-linux rename? >- bsdextrautils >- something else util-linux-extra. Unrelatedly, other non-essential binaries from util-linux should also move into this package, but this is only tangentially related. > * how should it be named? >- rename >- rename.ul >- something else > * where should it be installed? >- /usr/bin >- something else? /usr/bin/rename > * should it be managed with update-alternatives? No. My understanding is this would be a bug. Also, I subscribe to the idea that (pseudo-)essential packages should not use the update-alternatives mechanism. This last point might be easier with util-linux-extra. > * should there be a Conflicts or Breaks relation with the perl rename? I think this will be necessary. > If you feel unable to answer any of these, please say so. > > Thank you for taking the time to participate in this discussion. I would like to ask a question: under which constitution point will the CTTE act? > Helmut BR, Chris signature.asc Description: PGP signature
