[opensuse-packaging] Obsoletes < vs Obsoletes <=
Hi, in discussions etc. people say one should use < in the obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version However this does not reliably "work" when %version did not change across the change (e.g. changing EV from foo-1.0 towards libfoo-1.0), the old foo-1.0 will stick around because it is not obsoleted by libfoo-1.0. So "foo < %version" is actually bogus and should be either <=, or actually foo < %version-%release. <= makes technology unhappy ("package obsoletes itself"), so that leaves us with the %version-%release approach. Does baselibs.conf support obsoletes "foo < <version>-<release>" actually? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le dimanche 18 septembre 2011, à 20:07 +0200, Jan Engelhardt a écrit :
Hi,
in discussions etc. people say one should use < in the obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version
However this does not reliably "work" when %version did not change across the change (e.g. changing EV from foo-1.0 towards libfoo-1.0), the old foo-1.0 will stick around because it is not obsoleted by libfoo-1.0. So "foo < %version" is actually bogus and should be either <=, or actually foo < %version-%release. <= makes technology unhappy ("package obsoletes itself"), so that leaves us with the %version-%release approach. Does baselibs.conf support obsoletes "foo < <version>-<release>" actually?
Sascha mentioned this case in his talk about packaging best practices. The recommendation is the following: - if there's a version update at the same time, use < - if there's no version update, use <=, and add a comment specifying for which version this was done, so people know when it's safe to go to <. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hello, on Montag, 19. September 2011, Vincent Untz wrote:
Le dimanche 18 septembre 2011, à 20:07 +0200, Jan Engelhardt a écrit :
obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version
Sascha mentioned this case in his talk about packaging best practices.
The recommendation is the following:
- if there's a version update at the same time, use < - if there's no version update, use <=, and add a comment specifying for which version this was done, so people know when it's safe to go to <.
So far, so good, but: does it really make sense to use %version for the obsoletes? IMHO a hardcoded version would make more sense... For example, let's assume foo was renamed to bar, and the latest version of foo was 1.5. In the meantime, there is bar 5.0 - and a new project foo 2.0 that does something totally different than foo 1.5 or bar 5.0. With the above sniplet, foo would always be replaced by bar. What about: Obsoletes: foo <= 1.5 Provides: foo = %version This should still replace all old bar packages up to 1.5, but avoid the problem that foo 2.0 will be replaced even if it is something totally different. Opinions? Regards, Christian Boltz -- Geld. Wie profan. Mein Rechner braucht eine Champagnerkühlung beim downloaden. Glucker. Mich kühlt Astra. [Ratti in fontlinge-devel] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Sep 20, 2011 at 3:37 PM, Christian Boltz <opensuse@cboltz.de> wrote:
Hello,
on Montag, 19. September 2011, Vincent Untz wrote:
Le dimanche 18 septembre 2011, à 20:07 +0200, Jan Engelhardt a écrit :
obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version
I've got a project that may need this. == background == I am working with the next4 team and they have a ext4dev patch that allows a ext4dev module to be compiled. If that module is inserted, then that kernel will take the ext4dev filesystem type to mean the filesystem should be examined to see if it has snapshot support and if so, enable it if explicitly requested to. == My need. To go with the above module, e2fsprogs has to be extended to have the legacy programs mkfs.ext4dev, fsck.ext4dev, etc. handle this new definition of ext4dev (ext4dev is unused since the 2.6.29 kernel I think). That turns out to be trivial because there is remnant code in e2fsprogs to build those with no issues. My issue is in the packaging. I doubt I should submit a patch to update the core e2fsprogs package, so I was thinking of creating a e2fsprogs-ext4dev package. That package would provide all the same executatables and libraries as e2fsprogs (plus a couple), but the ext4dev versions of the exe's would be different. Is that logical? If so, is there an example package/specfile I could look at to see how they are handling the package name, provides, and obsoletes logic? Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tuesday 2011-09-20 23:10, Greg Freemyer wrote:
obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version
I've got a project that may need this.
== background == I am working with the next4 team and they have a ext4dev patch[...] My need. To go with the above module, e2fsprogs has to be extended to have the legacy programs mkfs.ext4dev, fsck.ext4dev, etc. handle this new definition of ext4dev (ext4dev is unused since the 2.6.29 kernel I think).
Yeah perhaps one should not call the effort 'ext4dev' but maybe 'ext4 with snapshots' :-)
My issue is in the packaging. I doubt I should submit a patch to update the core e2fsprogs package, so I was thinking of creating a e2fsprogs-ext4dev package. [...] handling the package name, provides, and obsoletes logic?
By using Obsoletes/Provides in this case, you enact zypper to automatically select your package during dependency resolution of another package's dependencies (say, perl-Bootloader). This of course is undesired, since your package contains components that are considered "fragile" by your very own definition. IOW, no Obsoletes/Provides for your case. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
I added the next4 / ext4dev / ext4 with snapshots mailing list in copy, just in case they wanted to comment. On Tue, Sep 20, 2011 at 5:34 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
On Tuesday 2011-09-20 23:10, Greg Freemyer wrote:
obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version
I've got a project that may need this.
== background == I am working with the next4 team and they have a ext4dev patch[...] My need. To go with the above module, e2fsprogs has to be extended to have the legacy programs mkfs.ext4dev, fsck.ext4dev, etc. handle this new definition of ext4dev (ext4dev is unused since the 2.6.29 kernel I think).
Yeah perhaps one should not call the effort 'ext4dev' but maybe 'ext4 with snapshots' :-)
It actually started 18 months ago or more as next4 (ext4 with snapshots). At some point and I believe with the support of the ext4 maintainer (Ted Tso) it was decided to leverage all the unused infrastructure related to the initial ext4dev rollout. When ext4 was rolled for production in the 2.6.30 timeframe, ext4dev basically became a legacy designation. So e2fsprogs, xfstests, and I guess other code has a support base for ext4dev, but no current use case. Obviously to enable this new code, the filesystem type would need: - to be ext4dev, - a new snapshot feature bit would need to be set on the filesystem, (that feature bit has been reserved in the ext4 superblock by Ted T'so for a year or more I believe) - the new ext4dev userspace tools would be needed. I'm not sure how / when Ted plans to rollout out next4/ext4dev/ext4 with snapshots. He's been saying for about 6 months that he would try to review the patches and get it into the next merge window. Obviously that has not happened yet. The patch itself is based on a production Filer that has been commercially sold for a couple years. So it has had a lot of field testing.
My issue is in the packaging. I doubt I should submit a patch to update the core e2fsprogs package, so I was thinking of creating a e2fsprogs-ext4dev package. [...] handling the package name, provides, and obsoletes logic?
By using Obsoletes/Provides in this case, you enact zypper to automatically select your package during dependency resolution of another package's dependencies (say, perl-Bootloader).
This of course is undesired, since your package contains components that are considered "fragile" by your very own definition.
IOW, no Obsoletes/Provides for your case.
I admit to not thinking about that. Just to be clear, the "fragile" components have legacy names which no one should be using. And they in and of themselves don't do anything special unless the user has also installed the ext4dev kernel module. So I don't think the new functionality could occur accidentally. ---- The patch I have causes a change to mkfs.ext4dev, etc. All the other instances of mkfs.* should be the same as the main package. Since mkfs.ext4dev are in normal e2fsprogs but use the same code as mkfs.ext4, my thought was to have my new e2fsprogs-ext4dev package simply redundantly provide everything in e2fsprogs. Is there a better way to cause my versions of *.ext4dev to be installed and not the ones from e2fsprogs? I guess I could submit a e2fsprogs patch to have it not build *.ext4dev, and then have my package (e2fsprogs-ext4dev) only provide those? Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, (forgot to reply to this...) Le mardi 20 septembre 2011, à 21:37 +0200, Christian Boltz a écrit :
Hello,
on Montag, 19. September 2011, Vincent Untz wrote:
Le dimanche 18 septembre 2011, à 20:07 +0200, Jan Engelhardt a écrit :
obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version
Sascha mentioned this case in his talk about packaging best practices.
The recommendation is the following:
- if there's a version update at the same time, use < - if there's no version update, use <=, and add a comment specifying for which version this was done, so people know when it's safe to go to <.
So far, so good, but: does it really make sense to use %version for the obsoletes? IMHO a hardcoded version would make more sense...
It really depends, there are two cases here: a) package got renamed: %{version} is fine b) upstream got renamed: then a fixed version might be better Case b should not be strict, imho, as I can see cases where the the upstream name simply got adapted a bit, but it's really the same team, working on the same project. For instance, if foo2 got renamed to foo, then using %{version} is fine, imho. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Christian Boltz -
Greg Freemyer -
Jan Engelhardt -
Vincent Untz