On 31 March 2017 at 12:00, Michael Schwendt <mschwe...@gmail.com> wrote:
> When you refer to removing a package "permanently", that is a fallacy.
> You cannot predict whether you may want to reintroduce a package some day.
> Even for a foo-static package there may be a reason why to build such a
> package again. Blocking a package name completely is not nice. It may be a
> 3rd party repo to reintroduce that package with a higher version or bumped
> Epoch. Or a local admin, who wants to keep it. Non-versioned Obsoletes
> make it more difficult to reintroduce the package, since you would need to
> get rid of the Obsoletes tags from installed packages *and* from the repo
> metadata first.
>
> Properly versioned Obsoletes also remove a package from the dist forever,
> provided that the package is not reintroduced in the future. Using macros
> is a trade-off, which also obsoletes any updates or upgrades the obsolete
> package may have had for older dist releases. Non-versioned Obsoletes is
> the big hammer and a sloppy solution. That a packager can violate the
> dist upgrade path is a general problem and not specific to versioned
> Obsoletes tags.
>
I see that you and other people proposing versioned Obsoletes rules never
ever analysed step by step whole scenario(s) or done kind of 10 min POC to
prove correctness/incorrectness of this. Looks like again .. it is result
of using (educated) guessing :(
OK, doesn't matter.
Let's try do this here step by step analysing exact scenarios with and
without versioned Obsoletes.
Package A, Version 1.0, release 1 has static subpackage
Package A, Version 2.0, release 1 has no longer static subpackage and main
A has obsolete rule for A-static
Package A, Version 3.0, release 1 has again static subpackage and by this
has no longer has obsolete rule for A-static.
Additional detail:
For the record: all exactly this kind of packages should have "Requires:
A-devel = %{version}-%release}" in static and A-devel should have at least
"Requires: A = %{version}-%{release}". However in or case it is meaningless
..
What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1" and just
"Obsolete: A-static" when new 3.0 will arrive?
What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was installed
before? Of course A-static will be uninstalled.
What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no longer
carries Obsolete rule -> A and A-static will be upgraded together.
Upgrade will be done as expected.
Above will happen no matter what kind dependencies are between A, A-devel
and A-static
Upgrade will be without errors no matter does A 3.0 contains versioned or
not versioned Obsolete because rm will in internal dependencies resolver
will reorder new A-3.0 package dependencies without obsolete *canceling
Obsolete rule from A-2.0 and what was exactly in those earlier A package
rules at such change of state is completely meaningless*
Conclusion: Using *versioned* Obsolete rules is pointless and here should
be used well known tool of logic (
https://en.wikipedia.org/wiki/Occam%27s_razor)
Q.E.D.
Exactly the same happens on swapping and rolling back swapping (sub)
packages names.
In other words:
- "permanent remove" package is never permanent and can be always rolled
back/reversed in next versions/releases. Such permanency is only matter of
agreement that we will (probably) never going to package something under
exact package name
- even current FPG point about swapping/changing packages names suggesting
use versioned is incorrect because swapping package names is like
"permanently remove package X .. but just for now". All works exactly this
way because as as I wrote "permanence of remove package X" is only matter
of some agreement and by definition is not possible to construct any
package names changes which will be not possible to reverse in next X
releases/versions.
What I wrote about using versioned Obsoletes rules is not a fallacy because
no one needs here to predict anything about future state of some packages
sets states.
Do you see this now?
.. your good intentions mixed with intuition tricked you. Don't worry you
are not the first and not the last :)
It is known that analyse consequences of +2 questions combined as long as
you are not kind of autistic person fails in case ~all humans on daily
bases.
Training/teaching The Engineers is about almost imprinting that this
threshold of fails is so close and main rule is testing, and testing again,
and again ..
So why I'm so sure that it works exactly like above? Because more than 20
years ago after writing first ever rpm spec file producing multiple
subpackages and publishing it (lesstif.spec) during my experiments but
before release it on RHCN ftp server I made typo in subpackage name. I
found it after I've installed those package on ~20 computers in Gdańsk
Technical Univ Physics Department student laboratory (to which as a student
I had root access). Because just before this I've organised my first
packages "repository" over NFS I've decided to make experiment and trying
to fix this by bumping package release with modified Obsolete rules.
Because it was late evening and I was tired I made another typo in first
fix so I made yet another modification->rebuild->publish->upgrade cycle and
.. I've succeeded on all those steps.
(however this JFDI version of lesstif.spec was never publically released)
No, at this time was no such things like yast, poldek, yum or dnf or even
apt adapted to manage rpm packages ..
I've been using just dumb/plain "rpm -Fvh /net/<nfs.server></repo/dir/>*".
BTW Epoch. Using Epoch is only for scenario when it is necessary roll back
to earlier version of *the same package* when such package *is installed*.
Obsolete rules is breaking such continuity and by this is not applicable
here.
For example after upgrade from 1.0 to 2.0 someone found critical bug in 2.0
and it is easier to just back to 1.0 on those systems which already done
upgrade to 2.0 as well.
Please have look on real examples like it was used in the past
https://www.redhat.com/archives/rpm-list/2005-March/msg00039.html
Epoch is for kind of Obsolete package themselves but from higher version
(because rolling back/fixing faulty release can be done by fixing
package->bumping Release->rebuild->publish).
Your example with taking care of 3rd party packages repos in distribution
like Fedora, if you will look on such scenario closer is as well
undefendable because if you would really want to take care of such packages
to force upgrade starting from installed such 3rd party packages it would
be necessary to bump Epoch in ALL Fedora packages after each new version or
package release. Even this could be impossible to force if such 3rd party
package may start using way higher values of Epoch, Pure nonse. Isn't it?
3rd party repos are not yours/mine/ours monkey .. so as well they are not
in yours/mine/ours circus.
If you are thinking that prepare some test.spec POC may take you to long
you can still test above using just pen and paper. Remember that rpm
dependencies resolver has own logic/mechanics which is not obvious, and is
able to resolve circular or complicated planar/non-planar graphs
dependencies. Sometimes on using plain rpm is possible to observe its work
as exact order of packages passed in "rpm -Uvh" parameters is not the same
as executed packages upgrade order.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
