Re: Transitional (dummy) packages considered silly
Emilio Pozuelo Monfort po...@debian.org writes: Goswin von Brederlow wrote: Russ Allbery r...@debian.org writes: Goswin von Brederlow goswin-...@web.de writes: Dpkg has the ability to vanish empty packages. A dummy package should be completly empty and not even contain a /usr/share/doc/. Such a package is explicitly forbidden by Debian Policy. You need to propose a Policy change if you want to do this. I believe it was discussed some time past, and the general consensus was against doing this, but I could be misremembering. Do you happen to know the chapter/section where that is said? Note that 12.7 Changelog files does not require a /usr/share/doc/changelog for native packages. 2.3. Copyright considerations - Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file `/usr/share/doc/package/copyright' (see Section 12.5, `Copyright information' for further details). That is already not quite true when /usr/share/doc/package is a link. Maybe that should be worded differently. I would also not call this explicitly. I do not believe this was written to disallow empty debs but to state the legal requirement that every copyrightable bit in Debian needs a copyright and license. As a though experiment: If you have no contents isn't a nonexistant file a verbatim copy of the nonexistant copyright and meaningless distribtuion license? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Russ Allbery r...@debian.org writes: Emilio Pozuelo Monfort po...@debian.org writes: Goswin von Brederlow wrote: Do you happen to know the chapter/section where that is said? Note that 12.7 Changelog files does not require a /usr/share/doc/changelog for native packages. 2.3. Copyright considerations - Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file `/usr/share/doc/package/copyright' (see Section 12.5, `Copyright information' for further details). Yup. And since a package necessarily includes metadata, including a package description, which is copyrightable material. Is the Packages.gz file then in violation of my packages license? It doesn't come with a copy of the GPL as required by my software. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
On Mon, Oct 05 2009, Goswin von Brederlow wrote: Is the Packages.gz file then in violation of my packages license? It doesn't come with a copy of the GPL as required by my software. :) In a narrow sense, this is also an argument you may make about any .deb whose license belongs in /usr/share/common-licenses; since the binary .deb does not contain the licenses required. If the end user uses alien to install it on, say, a fedora machine, the pointers to the license file would be left dangling. In a number of ways, individual bits of our OS are not distributable in isolation. manoj -- We have a equal opportunity Calculus class -- it's fully integrated. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Guillem Jover guil...@debian.org writes: On Wed, 2009-09-23 at 10:51:50 +0200, Goswin von Brederlow wrote: Magnus Holmgren holmg...@debian.org writes: When a binary package is renamed or split, as well as if several packages are merged under a new name, transitional packages are normally created, which depend on the new packages, which in turn Replaces and Conflicts with, and possibly Provides, the old packages. I find those dummy packages as silly to create as to uninstall after upgrading. Dpkg has the ability to vanish empty packages. A dummy package should be completly empty and not even contain a /usr/share/doc/. That way on installation the package pulls in its depends and then vanishes. So no more need to uninstall after upgrading. This only works if the superseeding packages Provide the old one though. Otherwise depends on the old package would become unsatisfied. That's not correct. dpkg only disappears packages that have been completely replaced while installing other packages. There's two cases for this: 1. The package to disappear has files that get completely replaced by the new one. Needs the Replaces field. 2. The disappearing package contains empty directories, and all of them are shipped as well by the new package. Does not need Replaces field, because directory takeover is an implicit Replaces, so this is actually a subcase of 1. dpkg will never disappear a packages just because it's empty w/o the previous conditions. And just to clarify, in no case the Provides field plays any role in the disappearing process. regards, guillem Ok, so one would need to have at least an empty directory (say /usr) in the package for it to disapear? Why the distinction? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Russ Allbery r...@debian.org writes: Goswin von Brederlow goswin-...@web.de writes: Dpkg has the ability to vanish empty packages. A dummy package should be completly empty and not even contain a /usr/share/doc/. Such a package is explicitly forbidden by Debian Policy. You need to propose a Policy change if you want to do this. I believe it was discussed some time past, and the general consensus was against doing this, but I could be misremembering. Do you happen to know the chapter/section where that is said? Note that 12.7 Changelog files does not require a /usr/share/doc/changelog for native packages. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
On Mon, Sep 28, 2009 at 11:04:25AM +0200, Goswin von Brederlow wrote: Ok, so one would need to have at least an empty directory (say /usr) in the package for it to disapear? Why the distinction? Because an empty package is valid (doesn't equivs create these?), and having Replaces: take effect and disappear a completely empty package would make it impossible to reinstall an empty package if some other package on the system declared a Replaces: on it. -- 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: Transitional (dummy) packages considered silly
Emilio Pozuelo Monfort po...@debian.org writes: Goswin von Brederlow wrote: Do you happen to know the chapter/section where that is said? Note that 12.7 Changelog files does not require a /usr/share/doc/changelog for native packages. 2.3. Copyright considerations - Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file `/usr/share/doc/package/copyright' (see Section 12.5, `Copyright information' for further details). Yup. And since a package necessarily includes metadata, including a package description, which is copyrightable material. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
On Thu, Sep 24, 2009 at 05:37:03PM +0200, Francesco P. Lovergine wrote:
What about moving those packages under a transitional Section in the
archive? That would allow users to easily detect and remove them
after dist-upgrades for instance, and it would also allow maintainers
to mark proper transitional/dummy packages.
I was thinking along the same lines (which is a line of thought
orthogonal to an implementation of a Supersedes field: we can have
both).
So, let's focus on the user problem: how can we empower users to
recognize, with some certainty transactional packages to remove. Once we
have that, we can add a specific package manager command (a-la apt-get's
autoremove that in one step removes them).
I see various ways of enabling such recognition:
- Status quo: grepping for transitional package in package
descriptions
- Archive section (i.e. Frankie's proposal): would ftp-master (Cc-ed)
be willing to pursue that road?
- Debtags. Apparently there's already a tag role::dummy whose
semantics seems to match transitional package (hence the name should
probably be better?).
However, if I check on my laptop I've about 20 transitional packages
installed (detected using status quo above) and some empiric tests
show that quite a lot of them do not have the role::dummy tag. This
means that, at least currently, the debtags way is not really enough
(or better: it looks to be sound, but not complete). I wonder why? Is
it just missing tags or is there some more serious infrastructure
problem? E.g.: is there a tag flow problem which erases tags from
transitional package of past versions when the package got removed
from the archive (but not necessarily from user machines?). Cc-ing
debtags-devel for advices.
- A new debian/control field, e.g. Transitional: yes
I see no clear winner among the above choices. The proposed solution of
using archive sections, for instance, has the drawback that you renounce
to the original section and hence you will partly defeat user actions,
e.g., removing all installed packages belonging to a given section.
Debtags is clearly meant to solve this problem, but for transitional
packages I'd like to have a solution which is both sound and
complete. Only with such properties I'd be confident of integrating a
clean up actions which we can recommend doing, e.g., in release notes.
Thoughts?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Transitional (dummy) packages considered silly
In gmane.linux.debian.devel.general Stefano Zacchiroli z...@debian.org wrote: [...] - Archive section (i.e. Frankie's proposal): would ftp-master (Cc-ed) be willing to pursue that road? [...] I always thought dummy transitional packages were supposed to be in section oldlibs anyway. cu andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Stefano Zacchiroli wrote: I see various ways of enabling such recognition: Recognizing transitional packages is only a small part of the problem. You also need to 'move' the 'non-automatic' flags to another package if needed. And I'm not sure there is currently enough information in (transitional or not) packages to do this automatically. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
On Sun, Sep 27, 2009 at 04:30:50PM +0200, Stefano Zacchiroli wrote: - Status quo: grepping for transitional package in package descriptions Transitional packages are often not defined as such in description. Too unsafe rely on keyword such as transitional, dummy, what else. This is sub-optimal IMHO. - Archive section (i.e. Frankie's proposal): would ftp-master (Cc-ed) be willing to pursue that road? - Debtags. Apparently there's already a tag role::dummy whose semantics seems to match transitional package (hence the name should probably be better?). That could be an alternative, but I would prefer a solution under full maintainer's control. Debtags currently is not AFAIK. And this is probably the reason of the mismatches below. However, if I check on my laptop I've about 20 transitional packages installed (detected using status quo above) and some empiric tests show that quite a lot of them do not have the role::dummy tag. This means that, at least currently, the debtags way is not really enough (or better: it looks to be sound, but not complete). I wonder why? Is it just missing tags or is there some more serious infrastructure problem? E.g.: is there a tag flow problem which erases tags from transitional package of past versions when the package got removed from the archive (but not necessarily from user machines?). Cc-ing debtags-devel for advices. - A new debian/control field, e.g. Transitional: yes This is equivalent to the archive solution, but it increases fields pollution. I have not a strong opinion about what's better. I see no clear winner among the above choices. The proposed solution of using archive sections, for instance, has the drawback that you renounce to the original section and hence you will partly defeat user actions, e.g., removing all installed packages belonging to a given section. I see no uses for such a selective removing. But that could be a pro for the control field. Debtags is clearly meant to solve this problem, but for transitional packages I'd like to have a solution which is both sound and complete. Only with such properties I'd be confident of integrating a clean up actions which we can recommend doing, e.g., in release notes. Thoughts? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
On Sun, Sep 27, 2009 at 07:22:27PM +0200, Vincent Danjean wrote:
Recognizing transitional packages is only a small part of the problem.
Agreed. As discussed in my post, that's the part of the problem which I
was trying to address.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Transitional (dummy) packages considered silly
On Sun, Sep 27, 2009 at 06:11:13PM +0200, Andreas Metzler wrote:
I always thought dummy transitional packages were supposed to be in
section oldlibs anyway.
According to the archive section description, that section is just for
transition *libraries* (as the name hints).
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Transitional (dummy) packages considered silly
On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote: When a binary package is renamed or split, as well as if several packages are merged under a new name, transitional packages are normally created, which depend on the new packages, which in turn Replaces and Conflicts with, and possibly Provides, the old packages. I find those dummy packages as silly to create as to uninstall after upgrading. What about moving those packages under a transitional Section in the archive? That would allow users to easily detect and remove them after dist-upgrades for instance, and it would also allow maintainers to mark proper transitional/dummy packages. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Magnus Holmgren holmg...@debian.org writes: When a binary package is renamed or split, as well as if several packages are merged under a new name, transitional packages are normally created, which depend on the new packages, which in turn Replaces and Conflicts with, and possibly Provides, the old packages. I find those dummy packages as silly to create as to uninstall after upgrading. Dpkg has the ability to vanish empty packages. A dummy package should be completly empty and not even contain a /usr/share/doc/. That way on installation the package pulls in its depends and then vanishes. So no more need to uninstall after upgrading. This only works if the superseeding packages Provide the old one though. Otherwise depends on the old package would become unsatisfied. Only problem is that this screws with the automatic/manual install flag. See below. I propose a new control field called e.g. Supersedes that will provide the same semantics. In its simplest form, a renamed package will declare that it Supersedes the old package name. That will be considered equivalent to conflicting with/replacing earlier versions of the superseded package, as well as providing a new version of it, just like a dummy package. Multiple packages can supersede the same package (but they should probably be the same version), and one package can of course supersede many others. This proposal should be feasible; APT scans all Packages lists searching for the best version of a given package to install, doesn't it? so it will be able to find the Supersedes fields at the same time. This would, among other things, solve the git problem; gnuit would supersede git, which would tell APT that the latter should be upgraded into the former, and that git the VCS is something else entirely. -- Magnus Holmgrenholmg...@debian.org Debian Developer Packages should tell when they superseed some other package. The conflicts/replaces/provides triplet was used for this in the past but no frontend ever looked for it. Also not every superseeding has used the triplet or should use it. I suggest that superseeding also includes a possible version as a package might only superseed an old version of something but not a newer one. Or a rename might be undone resulting in A superseeding B and B superseeding A. A version will tell the right order. Superseeding should also preserve the automatic/manual flag of the superseeded package. Currently if A was manually installed and becomes a dummy package then removing A will propose to remove the superseeding package too. WOrse if A vanishes as the superseeding packages would just silently appear in the removable list. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Pierre Habouzit madco...@madism.org writes:
On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
Note that transitional packages are seamless for users. When users has
foo in $stable, and foo gets renamed into bar in $stable +1, then there
is that:
$stable: package foo
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts foo}
$stable + 2: foo is dropped, replaces/provides/conflicts foo in bar can be
dropped.
After user has upgraded from $stable to $stable + 1, he doesn't have
'foo' anymore.
Yes, he does. Till he removes it manually currently.
Finally, I think your proposal doesn't work, because Supersedes cannot
work if two distinct binary packages Supersedes the same binary. We
can obviously ensure this doesn't happen in the _same_ Debian
distribution. I don't see how we can feasibly ensure it across different
releases in a sane way (and I know lots of people having deb lines for
stable, testing and sid in their sources.list).
Why? The frontend would say Foo is superseeded by multiple packages:
Bar, Baz, Buzz. Which one do you want?. Compare that to apt-get
giving a list of packages providing a virtual package when one tries to
install one.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Magnus Holmgren holmg...@debian.org writes: When a binary package is renamed or split, as well as if several packages are merged under a new name, transitional packages are normally created, which depend on the new packages, which in turn Replaces and Conflicts with, and possibly Provides, the old packages. I find those dummy packages as silly to create as to uninstall after upgrading. I propose a new control field called e.g. Supersedes that will provide the same semantics. In its simplest form, a renamed package will declare that it Supersedes the old package name. That will be considered equivalent to conflicting with/replacing earlier versions of the superseded package, as well as providing a new version of it, just like a dummy package. Multiple packages can supersede the same package (but they should probably be the same version), and one package can of course supersede many others. This proposal should be feasible; APT scans all Packages lists searching for the best version of a given package to install, doesn't it? so it will be able to find the Supersedes fields at the same time. This would, among other things, solve the git problem; gnuit would supersede git, which would tell APT that the latter should be upgraded into the former, and that git the VCS is something else entirely. -- Magnus Holmgrenholmg...@debian.org Debian Developer What about a case where the superseded package remains in Debian. To bring up an example from the past: You have both apache and apache2. apache2 superseds apache but apache is still available and apache2 is not just a rename but a new package providing a superior implementation of the older package. Could supersede be made to detect such a case? Frontends should suggest updating to apache2 but not force this or do so automatically. Maybe only supersedes + provides would go automatically and superseds alone would onyl suggest the update. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
On Sun, 20 Sep 2009, Pierre Habouzit wrote: So while I dismissed your idea at first thinking you wanted to make it a dpkg thing, now that I understand that you rather want it to be an /apt/ one, it makes really more sense to me. I also believe that it's something that would be nice to have. The point remains though that: - apt - dselect - aptitude - cupt must support that. I wouldn't put dselect on a blocker list for this feature. All the apt based tools should support it however (that also includes synaptic). Well, so, maybe you should try to talk to apt/aptitude/dselect/cupt guys to see what they think of the proposal :) I would add the required support in dpkg/dpkg-dev to make the field official if Apt maintainers were to implement some support of it. However I wonder if we should not generalize this so that we can add supplementary hints for package managers in the future... there might other kinds of information that could be used in optimizing upgrade paths. I know Ubuntu has their own upgrade tool (update-manager -d) precisely to be able to drive the upgrade more finely (sort of automatization of the order recommended in the release notes). Apt-Hints: supersedes ... Other possible hints: - no-auto-remove: for kernels, modules, firmwares (currently a hack in apt-get) - no-mark-auto: for metapackages so that the direct dependencies installed are not marked as automatically installed I'm sure we can come up with other over time, so it might be nice to have a generic solution right from the beginning. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Goswin von Brederlow goswin-...@web.de writes: Dpkg has the ability to vanish empty packages. A dummy package should be completly empty and not even contain a /usr/share/doc/. Such a package is explicitly forbidden by Debian Policy. You need to propose a Policy change if you want to do this. I believe it was discussed some time past, and the general consensus was against doing this, but I could be misremembering. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
On Wed, 2009-09-23 at 10:51:50 +0200, Goswin von Brederlow wrote: Magnus Holmgren holmg...@debian.org writes: When a binary package is renamed or split, as well as if several packages are merged under a new name, transitional packages are normally created, which depend on the new packages, which in turn Replaces and Conflicts with, and possibly Provides, the old packages. I find those dummy packages as silly to create as to uninstall after upgrading. Dpkg has the ability to vanish empty packages. A dummy package should be completly empty and not even contain a /usr/share/doc/. That way on installation the package pulls in its depends and then vanishes. So no more need to uninstall after upgrading. This only works if the superseeding packages Provide the old one though. Otherwise depends on the old package would become unsatisfied. That's not correct. dpkg only disappears packages that have been completely replaced while installing other packages. There's two cases for this: 1. The package to disappear has files that get completely replaced by the new one. Needs the Replaces field. 2. The disappearing package contains empty directories, and all of them are shipped as well by the new package. Does not need Replaces field, because directory takeover is an implicit Replaces, so this is actually a subcase of 1. dpkg will never disappear a packages just because it's empty w/o the previous conditions. And just to clarify, in no case the Provides field plays any role in the disappearing process. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
2009/9/19 Eugene V. Lyubimkin jackyf.de...@gmail.com:
Anton Piatek wrote:
This should really be done by the package management, not by the user.
It sounds like you are describing the following:
$stable: package foo
manually installed
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts
foo}
foo should now be marked as removeable, bar should be marked as
manually installed (i.e. take the state associated with foo)
Can any of that be achieved with postinst scripts?
That's a very bad idea IMO.
Care to elaborate?
Anton
--
Anton Piatek
email: an...@piatek.co.uk
blog/photos:http://www.strangeparty.com
pgp: [0xB307BAEF] (http://www.strangeparty.com/anton.asc)
fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Anton Piatek wrote:
2009/9/19 Eugene V. Lyubimkin jackyf.de...@gmail.com:
Anton Piatek wrote:
This should really be done by the package management, not by the user.
It sounds like you are describing the following:
$stable: package foo
manually installed
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts
foo}
foo should now be marked as removeable, bar should be marked as
manually installed (i.e. take the state associated with foo)
Can any of that be achieved with postinst scripts?
That's a very bad idea IMO.
Care to elaborate?
Doing that would:
1) interfere with a package manager (un)setting 'autoinstalled' status
2) require a big script snippet with uncertain logic and a number of guessings
Dealing with 'autoinstalled' property is a deal of a package manager only.
Trying to interfering will introduce the mess.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
Re: Transitional (dummy) packages considered silly
On lördagen den 19 september 2009, Pierre Habouzit wrote:
On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
When a binary package is renamed or split, as well as if several packages
are merged under a new name, transitional packages are normally created,
which depend on the new packages, which in turn Replaces and Conflicts
with, and possibly Provides, the old packages. I find those dummy
packages as silly to create as to uninstall after upgrading.
I propose a new control field called e.g. Supersedes that will provide
the same semantics. In its simplest form, a renamed package will declare
that it Supersedes the old package name. That will be considered
equivalent to conflicting with/replacing earlier versions of the
superseded package, as well as providing a new version of it, just like a
dummy package. Multiple packages can supersede the same package (but they
should probably be the same version), and one package can of course
supersede many others.
Well, I'm not sure what the practical gain is, could you please
elaborate on the suggested Supersedes: semantics ?
Note that transitional packages are seamless for users. When users has
foo in $stable, and foo gets renamed into bar in $stable +1, then there
is that:
$stable: package foo
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts
foo} $stable + 2: foo is dropped, replaces/provides/conflicts foo in bar
can be dropped.
After user has upgraded from $stable to $stable + 1, he doesn't have
'foo' anymore.
He still has the transitional package 'foo' until he decides to go looking for
transitional packages and removes it (after clearing the 'autoinstalled' flag
on 'bar'). If he doesn't do that before upgrading to $stable+2, there's a
chance that there is a different package 'foo' that 'foo' will be upgraded
to.
There is one point in having the transitional package: it ensures that
no package does try to take foo as a package name in $stable + 1 which
would then in turn confuse apt.
A transitional package doesn't strictly prevent a maintainer from uploading
another source package with a binary package that takes the place of the
transitional package, as long as the version of the new package is greater,
which it has to be even if the old package only exists in stable, doesn't it?
That is the state of the art. Could you please elaborate where and why
this field would help ?
FWIW I would be interested to read about a field semantics that would
solve the git issue properly.
IOW in lenny we have git being the GNU file manager stuff, and git-core
the VCS. If you find a scheme that would allow git-core to become git,
and git to become gnuit in _one_ release cycle[1] then your proposal is
worth it.
Let me elaborate on my last paragraph. The idea is that if 'bar' Supersedes
'foo', then versions of 'foo' greater than that of 'bar' (or an explicitly
declared version) are a different package and should not be considered for
upgrading 'foo'. For example:
lenny:
git 4.3.20-10
git-core 1:1.5.6.5-3+lenny2
squeeze:
gnuit 4.9.5-1
Supersedes: git (4.9.2-1)
git 1:1.6.4.3-2
Supersedes: git-core (1:1.6.4.3-2)
On upgrade, since gnuit supersedes git at version 4.9.2-1 (the first version
with the new name), it cuts off the path to git 1:1.6.4.3-2. So if you had
git you get gnuit, and if you had git-core you get git. Note that if you
explicitly ask for just git 1:1.6.4.3-2 when you have git 4.3.20-10, instead
of upgrading, you won't automatically get gnuit unless extra intelligence is
implemented.
Finally, I think your proposal doesn't work, because Supersedes cannot
work if two distinct binary packages Supersedes the same binary. We
can obviously ensure this doesn't happen in the _same_ Debian
distribution. I don't see how we can feasibly ensure it across different
releases in a sane way (and I know lots of people having deb lines for
stable, testing and sid in their sources.list).
If two packages supersede the same package 'foo', then both should be
installed in place of 'foo' on upgrade, but only if they supersede the same
version of it (I suppose that's how it will have to be done). So you can have
e.g. (modulo syntactic details) foo 1.3.7-3, bar 1.3.7-4 (Supersedes: foo
(1.3.7-4), a new foo 1:1.0.2-1, then later a foo-bar 1:1.2.0-3 that Supersedes
foo (1:1.2.0-3), and it will be possible to deduce that foo 1.3.7-3 should be
upgraded to bar 1.3.7-4 and not to foo-bar.
Multiple different packages reusing the same name in subsequent releases seems
pretty contrived to me, however.
All in all, I think your proposal is just a shorthand to make your
debian/control marginally smaller and having to write extensive
(slow[2]) patches to dpkg, but also britney, dak and pretty much
everything dealing with .debs, for absolutely no real gain wrt the
current state of stuff.
I will concede that Supersedes should not
Re: Transitional (dummy) packages considered silly
On Sun, Sep 20, 2009 at 06:16:52PM +0200, Magnus Holmgren wrote: On lördagen den 19 september 2009, Pierre Habouzit wrote: There is one point in having the transitional package: it ensures that no package does try to take foo as a package name in $stable + 1 which would then in turn confuse apt. A transitional package doesn't strictly prevent a maintainer from uploading another source package with a binary package that takes the place of the transitional package, as long as the version of the new package is greater, which it has to be even if the old package only exists in stable, doesn't it? I think either britney or dak should choke on that at some point. That is the state of the art. Could you please elaborate where and why this field would help ? FWIW I would be interested to read about a field semantics that would solve the git issue properly. IOW in lenny we have git being the GNU file manager stuff, and git-core the VCS. If you find a scheme that would allow git-core to become git, and git to become gnuit in _one_ release cycle[1] then your proposal is worth it. Let me elaborate on my last paragraph. The idea is that if 'bar' Supersedes 'foo', then versions of 'foo' greater than that of 'bar' (or an explicitly declared version) are a different package and should not be considered for upgrading 'foo'. For example: Actually Supersedes should always be versionned I think, which is something I missed, and make the thing pretty interesting in fact ... Finally, I think your proposal doesn't work, because Supersedes cannot work if two distinct binary packages Supersedes the same binary. We can obviously ensure this doesn't happen in the _same_ Debian distribution. I don't see how we can feasibly ensure it across different releases in a sane way (and I know lots of people having deb lines for stable, testing and sid in their sources.list). If two packages supersede the same package 'foo', then both should be installed in place of 'foo' on upgrade, but only if they supersede the same version of it (I suppose that's how it will have to be done). So you can have e.g. (modulo syntactic details) foo 1.3.7-3, bar 1.3.7-4 (Supersedes: foo (1.3.7-4), a new foo 1:1.0.2-1, then later a foo-bar 1:1.2.0-3 that Supersedes foo (1:1.2.0-3), and it will be possible to deduce that foo 1.3.7-3 should be upgraded to bar 1.3.7-4 and not to foo-bar. Multiple different packages reusing the same name in subsequent releases seems pretty contrived to me, however. All in all, I think your proposal is just a shorthand to make your debian/control marginally smaller and having to write extensive (slow[2]) patches to dpkg, but also britney, dak and pretty much everything dealing with .debs, for absolutely no real gain wrt the current state of stuff. I will concede that Supersedes should not imply Replaces or Conflicts, but merely be a hint to APT. Then neither dpkg nor britney nor dak should need to be patched. Though a question remains: Should dak reject a package that tries to supersede a package of which a newer version already exists in the archive? I don't think so; the other 'foo' could be uploaded before the superseding 'bar'. ... especially reading that. I answered thinking you meant Supersedes to be an alias for something complicated, not a hint for apt. As a hint, it's probably a worthwhile goal, and I -see- ways to even make it work for name reuse in subsequent releases. Actually with versioning enabled, it's even quite simple. Looking at your example, with = in the versions instead of equality to make it more robust, lenny: git 4.3.20-10 git-core 1:1.5.6.5-3+lenny2 squeeze: gnuit 4.9.5-1 Supersedes: git (= 4.9.5-1~) git 1:1.6.4.3-2 Supersedes: git-core (= 1:1.6.4.3-2~) When a user upgrades, then /apt/ can grok that the proper upgrade path for 'git' coming from a version = smaller than 4.9.5-1 is using gnuit instead. It can then just do what was suggested in another mail in the thread and migrate autoinstalled flags from git to gnuit. At the same way, the sole thing you need to prevent apt to consider upgrading git (aka gnuit) into git (the VCS) is to make sure that the new git has a strictly greater version than the package it replaces, which can always be done using the dreaded epochs (it's ugly, but fancy things like reusing a package name for two different things is hard, and it's logical there is a price to pay). So while I dismissed your idea at first thinking you wanted to make it a dpkg thing, now that I understand that you rather want it to be an /apt/ one, it makes really more sense to me. The point remains though that: - apt - dselect - aptitude - cupt must support that. I don't think in the end that britney or dak needs to grok this header after all, as britney isn't about upgrade paths of a given package, but rather trying to build the
Re: Transitional (dummy) packages considered silly
On fredagen den 18 september 2009, Eugene V. Lyubimkin wrote: Magnus Holmgren wrote: I propose a new control field called e.g. Supersedes that will provide the same semantics. In its simplest form, a renamed package will declare that it Supersedes the old package name. That will be considered equivalent to conflicting with/replacing earlier versions of the superseded package, as well as providing a new version of it, just like a dummy package. Multiple packages can supersede the same package (but they should probably be the same version), and one package can of course supersede many others. I support this, however with not implying Conflicts/Replaces/Provides when Supersedes is specified. Supersedes would be just a 'proposal' to a package manager to remove old package name and install the new one, i.e. explicitly declared upgrade path. You have a point, though I think that in the vast majority of cases the superseding package will in conflict with the superseded one. Supersedes should definitely not imply a Provides (with the current meaning), since that would interfere with the introduction of a new, unrelated package with the old name (although versioned dependencies can be used to solve ambiguities, and all packages that formerly depended on the old name must be updated to depend on the new name instead). Evidently letting a new package take over the name of another package without at least one release cycle in between is not something that should be recommended... -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Re: Transitional (dummy) packages considered silly
Magnus Holmgren wrote: On fredagen den 18 september 2009, Eugene V. Lyubimkin wrote: Magnus Holmgren wrote: I propose a new control field called e.g. Supersedes that will provide the same semantics. In its simplest form, a renamed package will declare that it Supersedes the old package name. That will be considered equivalent to conflicting with/replacing earlier versions of the superseded package, as well as providing a new version of it, just like a dummy package. Multiple packages can supersede the same package (but they should probably be the same version), and one package can of course supersede many others. I support this, however with not implying Conflicts/Replaces/Provides when Supersedes is specified. Supersedes would be just a 'proposal' to a package manager to remove old package name and install the new one, i.e. explicitly declared upgrade path. You have a point, though I think that in the vast majority of cases the superseding package will in conflict with the superseded one. Supersedes should definitely not imply a Provides (with the current meaning), since that would interfere with the introduction of a new, unrelated package with the old name (although versioned dependencies can be used to solve ambiguities, and all packages that formerly depended on the old name must be updated to depend on the new name instead). Nevertheless, there were no precedents (?) for some fields implying others, and I think there is no good reason to introduce it. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
Re: Transitional (dummy) packages considered silly
On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
When a binary package is renamed or split, as well as if several packages are
merged under a new name, transitional packages are normally created, which
depend on the new packages, which in turn Replaces and Conflicts with, and
possibly Provides, the old packages. I find those dummy packages as silly to
create as to uninstall after upgrading.
I propose a new control field called e.g. Supersedes that will provide the
same semantics. In its simplest form, a renamed package will declare that it
Supersedes the old package name. That will be considered equivalent to
conflicting with/replacing earlier versions of the superseded package, as
well
as providing a new version of it, just like a dummy package. Multiple
packages
can supersede the same package (but they should probably be the same
version),
and one package can of course supersede many others.
Well, I'm not sure what the practical gain is, could you please
elaborate on the suggested Supersedes: semantics ?
Note that transitional packages are seamless for users. When users has
foo in $stable, and foo gets renamed into bar in $stable +1, then there
is that:
$stable: package foo
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts foo}
$stable + 2: foo is dropped, replaces/provides/conflicts foo in bar can be
dropped.
After user has upgraded from $stable to $stable + 1, he doesn't have
'foo' anymore.
There is one point in having the transitional package: it ensures that
no package does try to take foo as a package name in $stable + 1 which
would then in turn confuse apt.
That is the state of the art. Could you please elaborate where and why
this field would help ?
FWIW I would be interested to read about a field semantics that would
solve the git issue properly.
IOW in lenny we have git being the GNU file manager stuff, and git-core
the VCS. If you find a scheme that would allow git-core to become git,
and git to become gnuit in _one_ release cycle[1] then your proposal is
worth it.
Finally, I think your proposal doesn't work, because Supersedes cannot
work if two distinct binary packages Supersedes the same binary. We
can obviously ensure this doesn't happen in the _same_ Debian
distribution. I don't see how we can feasibly ensure it across different
releases in a sane way (and I know lots of people having deb lines for
stable, testing and sid in their sources.list).
All in all, I think your proposal is just a shorthand to make your
debian/control marginally smaller and having to write extensive
(slow[2]) patches to dpkg, but also britney, dak and pretty much
everything dealing with .debs, for absolutely no real gain wrt the
current state of stuff.
[1] this is theorical discussion as such a proposal would need to be
implemented in dpkg, then pushed to user, then used, IOW only
squeeze+1 would be a target for Supersedes use anyway.
[2] yes slow, because for each package install, dpkg would have to
wonder if anything supersedes it, and deal with all the issues that
would arise if _two_ binary packages Supersedes the same thing.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
signature.asc
Description: Digital signature
Re: Transitional (dummy) packages considered silly
On 2009-09-19 21:18 +0200, Pierre Habouzit wrote:
Note that transitional packages are seamless for users. When users has
foo in $stable, and foo gets renamed into bar in $stable +1, then there
is that:
$stable: package foo
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts foo}
$stable + 2: foo is dropped, replaces/provides/conflicts foo in bar can be
dropped.
After user has upgraded from $stable to $stable + 1, he doesn't have
'foo' anymore.
There is one point in having the transitional package: it ensures that
no package does try to take foo as a package name in $stable + 1 which
would then in turn confuse apt.
That is the state of the art. Could you please elaborate where and why
this field would help ?
It would help frontends to transition the Automatically installed
status from bar to foo. Currently in this situation bar is marked as
automatic as it's a dependency of foo, and you need to do e.g.
aptitude unmarkauto bar; aptitude markauto foo so that
- removing foo does not accidentally remove bar as well;
- foo gets away as soon as it's no longer needed.
This should really be done by the package management, not by the user.
Sven
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
2009/9/19 Sven Joachim svenj...@gmx.de:
On 2009-09-19 21:18 +0200, Pierre Habouzit wrote:
Note that transitional packages are seamless for users. When users has
foo in $stable, and foo gets renamed into bar in $stable +1, then there
is that:
$stable: package foo
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts foo}
$stable + 2: foo is dropped, replaces/provides/conflicts foo in bar can be
dropped.
After user has upgraded from $stable to $stable + 1, he doesn't have
'foo' anymore.
There is one point in having the transitional package: it ensures that
no package does try to take foo as a package name in $stable + 1 which
would then in turn confuse apt.
That is the state of the art. Could you please elaborate where and why
this field would help ?
It would help frontends to transition the Automatically installed
status from bar to foo. Currently in this situation bar is marked as
automatic as it's a dependency of foo, and you need to do e.g.
aptitude unmarkauto bar; aptitude markauto foo so that
- removing foo does not accidentally remove bar as well;
- foo gets away as soon as it's no longer needed.
This should really be done by the package management, not by the user.
It sounds like you are describing the following:
$stable: package foo
manually installed
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts foo}
foo should now be marked as removeable, bar should be marked as
manually installed (i.e. take the state associated with foo)
Can any of that be achieved with postinst scripts?
Anton
--
Anton Piatek
email: an...@piatek.co.uk
blog/photos:http://www.strangeparty.com
pgp: [0xB307BAEF] (http://www.strangeparty.com/anton.asc)
fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Anton Piatek wrote:
This should really be done by the package management, not by the user.
It sounds like you are describing the following:
$stable: package foo
manually installed
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts
foo}
foo should now be marked as removeable, bar should be marked as
manually installed (i.e. take the state associated with foo)
Can any of that be achieved with postinst scripts?
That's a very bad idea IMO.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
Re: Transitional (dummy) packages considered silly
Magnus Holmgren wrote: When a binary package is renamed or split, as well as if several packages are merged under a new name, transitional packages are normally created, which depend on the new packages, which in turn Replaces and Conflicts with, and possibly Provides, the old packages. I find those dummy packages as silly to create as to uninstall after upgrading. Seconded. I propose a new control field called e.g. Supersedes that will provide the same semantics. In its simplest form, a renamed package will declare that it Supersedes the old package name. That will be considered equivalent to conflicting with/replacing earlier versions of the superseded package, as well as providing a new version of it, just like a dummy package. Multiple packages can supersede the same package (but they should probably be the same version), and one package can of course supersede many others. I support this, however with not implying Conflicts/Replaces/Provides when Supersedes is specified. Supersedes would be just a 'proposal' to a package manager to remove old package name and install the new one, i.e. explicitly declared upgrade path. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer signature.asc Description: OpenPGP digital signature
