On Sun, 2022-01-23 at 17:43 -0500, Theodore Y. Ts'o wrote:
That only works if there are no other packages depending on those
shared libraries which are coming from other source packages.
I don't think that is true, I believe you can put multiple things in
the depends section of an shlibs file and dpkg-shlibdeps will propagate
that to reverse dependencies just fine. From the manual pages it looks
like the same applies to the symbols files. I found on my system that
there are *already* packages that do something similar (see below).
...
Hi Paul and others,
its surely an interesting topic how to avoid binary name changes and its
also interesting to discuss ABI changes and workarounds.
However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic. I really want to know
that policy of ftpmaster and I really would like to see that documented
and I'm afraid that thread is drifting away from the original topic
that I will not get any answer on this.
On Mon, Jan 24, 2022 at 08:15:30AM +0100, Andreas Tille wrote:
its surely an interesting topic how to avoid binary name changes and its also interesting to discuss ABI changes and workarounds.
However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic.
As far as I know, ftpmaster requires a long, laborious review every
single time there is a new binary package released. As a result, it
strongly disincentivizes maintainers from packaging up new releases
because it's a pain in the posterior.
Even if it isn't formal policy, the long delay has happened enough
times that I just assume it will be there, and it influences my
behavior accordingly.
However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic. I really want to know
that policy of ftpmaster and I really would like to see that documented
and I'm afraid that thread is drifting away from the original topic
that I will not get any answer on this.
So again: I see a conflict in my interpretation of the mail[1] (original posters again in CC) which suggests "an auto-approver" and what I'm
currently observing and I would be really happy if we can document the
policy for changed (and new) binary names of existing source packages.
To give another example which has nothing todo with ABI changes:
Currently I'm afraid of splitting some Arch: all data from some
Arch: any package since I'm simply afraid of the changed package
sticking long in new queue. I know this is bad - but I consider
users waiting for package updates worse.
As far as I know, ftpmaster requires a long, laborious review every
single time there is a new binary package released. As a result, it
strongly disincentivizes maintainers from packaging up new releases
because it's a pain in the posterior. A while back, people asked me I
could update f2fs-tools, and it was shortly before the release freeze,
and even though there was apparently security fixes involved that
would be fixed in the latest version of f2fs-tools, I knew there would
be no point, since there was no way the package would squirt out the
review pipeline before the release freeze.
Even if it isn't formal policy, the long delay has happened enough
times that I just assume it will be there, and it influences my
behavior accordingly.
On Mon, Jan 24, 2022 at 8:15 AM Andreas Tille <andreas@an3as.eu> wrote:
However, my point was that I want to know what policy ftpmaster applies
to new binary names and to focus on this topic. I really want to know
that policy of ftpmaster and I really would like to see that documented
and I'm afraid that thread is drifting away from the original topic
that I will not get any answer on this.
So again: I see a conflict in my interpretation of the mail[1] (original posters again in CC) which suggests "an auto-approver" and what I'm currently observing and I would be really happy if we can document the policy for changed (and new) binary names of existing source packages.
Since I feel my mail went lost in the discussion, here again my opinion:
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:04:55 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |