Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Fri, Sep 6, 2013 at 7:05 PM, Steve Langasek wrote: > Now, maybe apt could consider a package a replacement only if pkgA > Replaces/Provides pkgB, *and* pkgB is no longer available. Are there cases > where that would give the wrong result? Is it practical to implement? Depends I guess on how much you value slight derivations from the norm. APT detects "obsolete" packages in its ProblemResolver and gives those a small penalty in conflict resolution, but I am not sure its a good idea to not only increase the penalty but let it cause actions by itself: Many people have multiple releases in their sources.list, so a package is not really disappearing – or takes quiet a while until it disappears. On the other hand packages sometimes disappear "temporarily" in testing. Also, sometimes packages disappear from stable – so while its a good idea to do something about those, I would say this is the wrong way of doing it as such an automated change contradicts stable. (and it doesn't work for the more common cases of packages which disappear, but have no replacement as such) What MIGHT (I haven't really though about it yet) work is limiting it to provides+replaces(+breaks) in the same source package, but I am not sure it makes that much sense to introduce complex rules for dependency relations if the current "simple" rules are already not understood by everyone (like breaks vs. conflicts). Personally, I would say we need a hints file just like britney and co have, but for package managers which tells them that this package is gone and a) can be replaced automatic by foo b) the user should decide between foo, bar, baz (this info is usually available in prosa in the RoM/RoQA bugreport) c) has no (free) replacement d) is no longer needed … Not that this would make the life of a maintainer necessarily easier, but it at least frees the user (and the package manager) from deciding if this remove requires user-attention or is just boring house-keeping. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fatnijufhoosqmencpjuozc-83mp7dmwmguzlajwdj...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Fri, Sep 06, 2013 at 03:16:34PM +0100, Simon McVittie wrote:
> On 06/09/13 10:17, David Kalnischkies wrote:
> > For example, you made mplayer2 now an upgrade for mplayer.
> > I am not sure that is what their maintainers/upstreams intend.
> > (maybe it is, but I am not keen on letting foo2/foo-ng maintainer
> > decide what is a good upgrade path for foo – that should really
> > be decided by foo maintainer).
> In controversial cases, can't we avoid this by social pressure ("don't
> do that, it's rude")?
The issue David is raising is that this is a semantic change; while many
packages would work fine by interpreting Replaces+Provides the way you
describe, there are some that wouldn't, and under Policy these packages are
not "wrong" today. How do we transition to this new behavior on the part of
apt without inconveniencing users with wrong results?
Now, maybe apt could consider a package a replacement only if pkgA
Replaces/Provides pkgB, *and* pkgB is no longer available. Are there cases
where that would give the wrong result? Is it practical to implement?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Fri, Sep 6, 2013 at 4:16 PM, Simon McVittie wrote:
> On 06/09/13 10:17, David Kalnischkies wrote:
>> For example, you made mplayer2 now an upgrade for mplayer.
>> I am not sure that is what their maintainers/upstreams intend.
>> (maybe it is, but I am not keen on letting foo2/foo-ng maintainer
>> decide what is a good upgrade path for foo – that should really
>> be decided by foo maintainer).
>
> In controversial cases, can't we avoid this by social pressure ("don't
> do that, it's rude")?
I should have noted that this was a bonus – the key point is that there
must be a way for foo2/foo-ng maintainers to declare that they provide
a (more or less) feature compatible replacement, and they do it with
exactly those relations as this is how debian-policy defines them, so
they can't be reinterpreted.
As we saw in "Debian Cosmology": You can easily change an init
system, but don't you dare to change a package manager …
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fdr8-oz0yfc6kqagmtmgi+a_5f+bc9fucwqtblnjs7...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On 06/09/13 10:17, David Kalnischkies wrote:
> For example, you made mplayer2 now an upgrade for mplayer.
> I am not sure that is what their maintainers/upstreams intend.
> (maybe it is, but I am not keen on letting foo2/foo-ng maintainer
> decide what is a good upgrade path for foo – that should really
> be decided by foo maintainer).
In controversial cases, can't we avoid this by social pressure ("don't
do that, it's rude")?
At the moment, the way to "force" an package to be superseded is a
transitional package built by foo2 that "takes over" a binary package
name from foo1. It would be entirely possible for the systemd
maintainers to upload src:systemd with a transitional sysvinit package
that depends on systemd-sysv, for instance. They don't do that, of
course, because it would be unwelcome - but it is technically possible.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5229e3c2.5090...@debian.org
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Thu, Sep 5, 2013 at 11:34 PM, Philipp Kern wrote: > On 2013-09-05 11:15, David Kalnischkies wrote: > [ Provides/Replaces up thread ] > >> The policy defines two uses of Replaces: > > […] > >> So my simple question is, which combination of relations should that >> be that tells a smart package manager to upgrade pkgA to pkgB ? > > > What about pkgB replacing and providing pkgA? Because its usually an error to just replace a package without breaking/conflicting against it in which case it looks suspiciously like 7.6.2 – also just take the examples I mentioned and think about what happens: For example, you made mplayer2 now an upgrade for mplayer. I am not sure that is what their maintainers/upstreams intend. (maybe it is, but I am not keen on letting foo2/foo-ng maintainer decide what is a good upgrade path for foo – that should really be decided by foo maintainer). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fd+bkrjnprzcdssgq3ar0z205o3h4eqpryi9zn0y_5...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On 2013-09-05 11:15, David Kalnischkies wrote: [ Provides/Replaces up thread ] The policy defines two uses of Replaces: […] So my simple question is, which combination of relations should that be that tells a smart package manager to upgrade pkgA to pkgB ? What about pkgB replacing and providing pkgA? Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19738307c26706ba63dd4207dfd47...@hub.kern.lc
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Wed, Sep 4, 2013 at 8:59 PM, Sune Vuorela wrote: > On 2013-09-04, Steve Langasek wrote: >> Unless apt has gotten smarter recently (which is not out of the question), >> no. It's a common misconception that apt will care about Provides/Replaces >> for selecting new packages on dist-upgrade, but while it seems like a nice >> idea, TTBOMK it's never been implemented. The policy defines two uses of Replaces: 7.6.1 Overwriting files in other packages – this is completely ignored by APT as that could be anything from "replacing a single file" over "fighting with this package over a few filenames" to "replacing all files". 7.6.2 Replacing whole packages, forcing their removal – there is the common believe that this allows all kinds of magic to happen, but no, it doesn't: The hole paragraph doesn't mention upgrades once, because there is no upgrade path. Not between mail-transport-agents, httpds, editors, "node", "git" or "mplayer" packages (random examples, no critic). So my simple question is, which combination of relations should that be that tells a smart package manager to upgrade pkgA to pkgB ? And does this combination also survives in the real world in which many maintainers e.g. still haven't got the difference between breaks and conflicts or depends, recommends and suggests? > Over in RPM land, I think they have a Obsoletes relation for a 'you > should consider this package a successor to package' APT has support for it since 2001. No idea how functional it is nowadays though as the apt-rpm fork from there this probably came is just as frozen. There should be a discussion about it in that timeframe, too. I remember seeing one at some point in my history-digging, can't find it now though. I think the most interesting point against such a relation might be: Package: aptitude Obsoletes: apt (Not that we would be in a fight, but many people think we are, so lets just add some fuel for them. KDE & Gnome works just as well) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fB_rmGTBPRYzu5HSJo_=eyigfqrlqtmzyh0ebjlg1u...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
severity 721838 whishlist tags 721838 pending thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130905004837.gh1...@gamma.logic.tuwien.ac.at
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On 2013-09-04, Steve Langasek wrote: > Unless apt has gotten smarter recently (which is not out of the question), > no. It's a common misconception that apt will care about Provides/Replaces > for selecting new packages on dist-upgrade, but while it seems like a nice > idea, TTBOMK it's never been implemented. Over in RPM land, I think they have a Obsoletes relation for a 'you should consider this package a successor to package' I have missed such a thing from time to time. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnl2f0p4.hsi.nos...@sshway.ssh.pusling.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
clone 709758 -1
reassign -1 src:texlive-lang
retitle -1 Transitional packages for going-away texlive-lang-*
thanks
I'm cloning the original bug report to make a new report for this
issue as described by Lucas:
Lucas Nussbaum writes ("Re: Bug#709758: Replacing a binary package by another
one(was: Communication issue?)"):
> OK, let's try again:
> - in wheezy, install texlive and texlive-lang-dutch
> - dist-upgrade to sid: texlive-lang-dutch is removed, texlive-lang-european
> is not installed
> That's wrong.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21031.15009.165271.106...@chiark.greenend.org.uk
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On 04/09/13 at 20:52 +0900, Norbert Preining wrote: > On Mi, 04 Sep 2013, Holger Levsen wrote: > > which other binary packages build by texlive-lang do you consider > > "pathological to use"? > > I considered the installation of one -lang package by itself without > actual latex package pathological. OK, let's try again: - in wheezy, install texlive and texlive-lang-dutch - dist-upgrade to sid: texlive-lang-dutch is removed, texlive-lang-european is not installed That's wrong. > > Holger, who considers just to build-depend on texlive-lang-all | and be > > > > done with this > > Since TL2005 that is nearly 8 years ago we practiuically haven't change > anything in the naming. > > And now that there are a few changes ... sudenly the world collapses. It's not about world collapse. It's about doing upgrades without removing functionality when it's possible, which is something we care about in Debian AFAIK. Why should texlive be different? Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130904121047.ga6...@xanadu.blop.info
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Mi, 04 Sep 2013, Holger Levsen wrote: > which other binary packages build by texlive-lang do you consider > "pathological to use"? I considered the installation of one -lang package by itself without actual latex package pathological. > Holger, who considers just to build-depend on texlive-lang-all | and be > > done with this Since TL2005 that is nearly 8 years ago we practiuically haven't change anything in the naming. And now that there are a few changes ... sudenly the world collapses. Ohh, I have to be careful otherwise Ian comes agian after me threatening me with consequences ... soo scary. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130904115204.ga14...@gamma.logic.tuwien.ac.at
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
Hi, On Mittwoch, 4. September 2013, Norbert Preining wrote: > Yes, and? Was the dist-upgrade disturbed? > We are talking about normal systems, that is having telxive or texlive-full > installed. Not pathological cases of only t-l-d installed. wheezy has: Package: texlive-lang Binary: texlive-lang-african, texlive-lang-arabic, texlive-lang-armenian, texlive-lang-cjk, texlive-lang-croatian, texlive-lang-cyrillic, texlive-lang- czechslovak, texlive-lang-danish, texlive-lang-dutch, texlive-lang-finnish, texlive-lang-french, texlive-lang-german, texlive-lang-greek, texlive-lang- hebrew, texlive-lang-hungarian, texlive-lang-indic, texlive-lang-italian, texlive-lang-latin, texlive-lang-latvian, texlive-lang-lithuanian, texlive- lang-mongolian, texlive-lang-norwegian, texlive-lang-other, texlive-lang- polish, texlive-lang-portuguese, texlive-lang-spanish, texlive-lang-swedish, texlive-lang-tibetan, texlive-lang-english, texlive-lang-vietnamese, texlive- lang-all, ptex-bin sid has: Package: texlive-lang Binary: texlive-lang-african, texlive-lang-arabic, texlive-lang-cjk, texlive- lang-cyrillic, texlive-lang-czechslovak, texlive-lang-english, texlive-lang- european, texlive-lang-french, texlive-lang-german, texlive-lang-greek, texlive-lang-indic, texlive-lang-italian, texlive-lang-other, texlive-lang- polish, texlive-lang-portuguese, texlive-lang-spanish, texlive-lang-all, ptex- bin, thailatex which other binary packages build by texlive-lang do you consider "pathological to use"? > I *can* provide transitional packages to make it nice for the user > experience. I don't remember a requirement in the Debian policy for that. #569219 and #323066 suggest this is a best practice for years. https://wiki.debian.org/PackageTransition might be helpful too. cheers, Holger, who considers just to build-depend on texlive-lang-all | and be done with this signature.asc Description: This is a digitally signed message part.
