eam might be interested in some of the tipps and tricks
from https://wiki.debian.org/InstructionSelection to use more/less
instructions as needed than the baseline.
On a sidenote: I would have expected this thread on d-mentors.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ific for that filesystem, it is just the only
known filesystem that lacks the feature apt uses otherwise: mapping
a file – its binary cache – into shared memory, see mmap(2)).
And yet, somehow, more than a decade later, people still use apt on other
filesystems (I kinda suspect "only" nowadays actually).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
eople grossly overestimate how easy it is for
packages to be upgraded individually (compare: t64 testing migration).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
exist) so that
we have to help them by generating work for many people and potentially
new upgrade problems for everyone – or if we declare them, existing or
not, a non-issue at least for the upgrade to trixie.
And on a sidenote: I would advise to reconsider interacting with dpkg
too casually – but luck is probably on your side in any case.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
able is known to exhibit the
required setup).
(I will write another mail in another subthread about the finer details
of what interacting with dpkg in an upgrade means and what might be
problematic if you aren't careful – in general, not just with aliasing)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Mon, Dec 04, 2023 at 01:13:43PM +0100, Helmut Grohne wrote:
> David Kalnischkies made me aware […]
Oh, did he? I think he wanted to tell you something else… 😉
As IRC seems to be really bad at transporting complicated things (who
had guessed?) and I need to sort my thoughts anyhow let
t is also why an arch:all package
is not "naturally" also "Multi-Arch: foreign".
> provide clones of a single package list for every architecture explicitly,
> and having to do so whenever a new one appears.
So yeah, if you want you can ship only an -all/Packages fil
g.
I guess the day after ~tomorrow groff will migrate as well – assuming
dgit was really your only problem.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
changes
with every revision), but close enough. At least more realistic than
that this software wasn't changed since the start of the unix epoch…
So please drop this again if its no longer needed.
Best regards
David Kalnischkies
P.S.: d-devel@ isn't entirely wrong as this is suf
as-wanted basis)
Can you recommend a relatively safe & old version to use instead of
< 3.5 which doesn't need bumping next month but is also available in
most semi-current releases of all major distributions (as that is what
most upstreams will care about if they don't hav
are easy to diagnose and fix. 'You "might" have some "random"
files not present on disk. So your system might not even boot or spawns
interdimensional portals. You better reinstall…' is not the type of
thing you wanna here from support.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Sun, Dec 18, 2022 at 06:08:57PM +0100, Johannes Schauer Marin Rodrigues
wrote:
> Quoting David Kalnischkies (2022-12-18 17:18:28)
> > On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote:
> > > Then there is "e2fsprogs", which apt seems to treat as i
for disliking it. Users are the worst,
I said it here first. But no problem, there usually is an option to
change anything in apt. If not, we can usually add it.
Just don't assume that the behaviour you prefer will be the default.
We have a strong tendency to make everyone unhappy.
(I should
s a hack,
not a role model. It is barely acceptable only because it effects only
a tiny fraction of our user base so far. And even for those, I would
like apt to help not installing broken packages (but that is another
topic).
So, who is gonna take the blame for deciding this for everyone?
Best regards
David Kalnischkies
[0]
https://salsa.debian.org/apt-team/apt/-/blob/main/apt-private/private-update.cc#L88-106
signature.asc
Description: PGP signature
On Mon, Oct 10, 2022 at 08:50:49AM +0800, Paul Wise wrote:
> On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote:
> > I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'.
>
> That sounds interesting and would be nice generally, however...
>
ng an apt dev… bringing all those nitty-gritty details to
policy would certainly be an interesting endeavour but if it would
really be a service to human kind^W^Wcontributors I am not so sure even
if its frequently used as an argument against MultiArch and related
projects.
Best regards
David Kal
(hence why apt likes to go on a remove spree if that is
deemed more beneficial), but that would lead us too far off-topic here…
So, could that be an acceptable Option c) ?
Best regards
David Kalnischkies
¹ this example was explicitly chosen as its possible that you
want to use them
ould use it, it should be told via the Release files,
which only stable does currently, stable-updates and stable-security
rely on apts built-in fallback which is sad)
Best regards
David Kalnischkies
P.S.: As I was quoted already, as a side note: I am not against nor in
favour of trimming; I am j
On Thu, May 26, 2022 at 08:50:21AM +0200, Marc Haber wrote:
> On Wed, 25 May 2022 20:21:03 +0200, David Kalnischkies
> wrote:
> >apt actually marks dependencies
> >of packages in section metapackages as manually installed if the
> >metapackage is removed due to t
f APT::Never-MarkAuto-Sections
in apt or reconsider having tasks be in their own Section, personally
I would prefer the later.
There are many other packages which feel like metapackages, but aren't
for apt as they are in the 'wrong' section – which is what I meant later
on in the mail, but that was arguably very well hidden.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
r
than recommends.
(And yes, apt installs new recommends in upgrades since literal decades,
so that is absolutely not a reason to use depends…)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
would be happy if you
would try to interact with us from the apt team, I don't think we
have the resources to help you with packaging through.)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
lly it would be
resolved regardless, but /usr-merge undoubtedly makes heavy use of it
so in an ideal world those interested in it would not only acknowledge
the problems but actually work together to resolve them.
Sadly, that isn't the world we seem to be stuck in at all.)
Best regards
Dav
On Wed, Nov 10, 2021 at 01:48:07AM +0200, Uoti Urpala wrote:
> David Kalnischkies wrote:
> > As the transition hasn't started everyone not already merged is currently
> > deferring it. That is true for those who upgrade daily as well as for
> > those people who seemin
On Tue, Nov 09, 2021 at 08:44:52PM +, Simon McVittie wrote:
> On Tue, 09 Nov 2021 at 19:01:18 +0100, David Kalnischkies wrote:
> > On Tue, Nov 09, 2021 at 03:21:25PM +, Simon McVittie wrote:
> > (Minus that for 12 it is technically still supported as long as it
> > r
don't see the harm of having an official opt-out of the
opt-out as long as it happens in time.
(Perhaps it comes with the job as apt maintainer, but I don't "discard
and redo" systems or even chroots… upgrades until hardware failure…
my current build chroots are fr
sly decided to forgo the automatic
transition for whatever reason (lets say to test build packages on that
box) I also have a standard way of triggering the conversion by calling
dpkg-reconfigure on usrmerge at leisure before the 13 upgrade.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ist files could contain both formats, but
I opted to change that as of course countless things poking into those
files broke left and right.
cups used to detect if it ran on a Debian-like system by checking the
sources.list file for deb entries… I doubt it does nowadays as there are
countless bet
-apt. I am sure we will work something out even if in this
case it might very well be new code nobody really uses for years (as is
common in apt land – backward compat be damned 😉).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
to an apt-thread on debian-devel…
(so now, where were I before this 'emergency call' came in… mhhh)
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Sun, Sep 12, 2021 at 03:10:27AM +, Paul Wise wrote:
> On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote:
> > Because this thread started with the idea to switch the default of d-i
> > and co to another URI. If you target only apt then you still need
> > a solut
On Fri, Sep 10, 2021 at 11:08:38AM -0400, Michael Stone wrote:
> On Fri, Sep 10, 2021 at 04:33:42PM +0200, David Kalnischkies wrote:
> > On Thu, Sep 09, 2021 at 08:53:21AM -0400, Michael Stone wrote:
> > > The only thing I could see that would be a net gain would be to
file.
JFTR: auto-apt-proxy has nothing to do with sources. It is true that
apt-cacher-ng (and perhaps others) have a mode of operation in which you
prefix the URI of your (in that case caching) proxy to the URI of the
actual repo, but that isn't how a proxy usually operates and/or is
configured.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
everywhere' configuration). In this regard apt is
stricter than a normal webbrowser (a mirror list acquired via https can
redirect to http mirrors though, but see the man pages for details).
Best regards
David Kalnischkies
¹ which deb.d.o sort of is just that it is nowadays done via SRV ins
On Mon, Aug 30, 2021 at 11:53:59AM +0100, Colin Watson wrote:
> On Mon, Aug 30, 2021 at 12:30:49PM +0200, David Kalnischkies wrote:
> > So, while for some/most usecases something akin to DynamicUser would be
> > enough, for others a more stable user would be preferred and then the
pt operates in.
I would be happy to be wrong through as it isn't exactly my dream to
make apt a decent service manager even through apt starts a lot
of processes, so a lot of management could and should be done here…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
orm of 'man
in the middle' "attack" https has no chance of preventing or detecting.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
es me very sad on many levels.
(I wrote this before reading Guillems replies which end on a similar
note even though he comes from the opposite end – dpkg worried about
the finer file-level details and apt about the general package-level
picture meeting halfway as usual… kinda funny)
Best regar
t remember of the top of
my hat. There are likely more problems as it is easier to just set the
clock approximately correct than to remember all the workarounds in
"the time of need"…
Best regards
David Kalnischkies
¹ okay, ~15 years of apt-secure are not exactly ever, but close enough.
signature.asc
Description: PGP signature
all over the clients as you
need some form of opt in at least. So far, that opt in was using http.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
d co.
There aren't that many (so far).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Mon, Aug 16, 2021 at 03:13:48PM +0200, Marco d'Itri wrote:
> On Aug 16, David Kalnischkies wrote:
> > Is perhaps pure existence not enough, do I need to provide an upgrade
> > path as simple as possible as well?
> If you have specific ideas about how the upgrade path co
;you have
to do it manually" so far. Surely you came up with something a lot
better after all those years.
Best regards
David Kalnischkies
P.S.: For the avoidance of doubt: apt-get is of course going nowhere,
but that cuts both ways: It isn't changing as your fingers hate change –
so e.g.
On Sun, Aug 15, 2021 at 05:52:06PM +0100, Simon McVittie wrote:
> On Sun, 15 Aug 2021 at 11:52:21 +0200, David Kalnischkies wrote:
> One way out of this would be to say that it is a RC bug for packages
> in bookworm to have different contents when built in equivalent
> merged-/usr
On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote:
> On Sat, 14 Aug 2021 at 16:59:24 +0200, David Kalnischkies wrote:
> > Wouldn't it be kinda strange to have the chroots building the packages
> > for the first bookworm release using a layout which isn't
On Sat, Aug 14, 2021 at 02:26:29PM +0100, Simon McVittie wrote:
> On Sat, 14 Aug 2021 at 14:33:44 +0200, David Kalnischkies wrote:
> > the current 'transition' plan is to have the
> > release notes nudge all people who upgrade instead of reinstall their
> > systems,
an open question for them
still as nobody is running the upgrader in there of course.
See also https://bugs.debian.org/985957.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ign by default anyhow)
Best regards
David Kalnischkies
P.S.: I picked out only this line as I think most of the rest is more
or less discussed to death already in other sub-threads and at times
actually objectively wrong – like the amount of packages shipping
something in /bin and co – so I don&#x
y of course all use different LESS flags to begin with).
So, before I am rushing off to do whatever I like, could we perhaps
agree on a "sensible-restricted-pager" (I dare not to name it secure…)
sort-of implementation first?
Oh and, btw, there is no point¹ in running 'apt chang
e -o Acquire::AllowUnsizedPackages=1 to disable this check.
Or, simply don't try to reinstall packages for (probably) no reason…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
e are willing to accept, one we are unwilling to postpone,
and one we intend to win".
Lets see how that will go.
Cavendish surprised most experts, too.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Fri, May 28, 2021 at 05:12:01PM +0100, Simon McVittie wrote:
> On Thu, 27 May 2021 at 16:53:45 +0200, David Kalnischkies wrote:
> > dpkg has the notion of "disappearing packages" (packages which have no
> > files left on a system) which could solve this cleanup
solvers like aspcud, but
those usually do not concern themselves too much with upgrades, but are
mostly used in build-chroot constructions, so you might get away without
it (see also optimisation criteria "less removals" from above).
As the number increases we would also need an "upgrade" command which
allows those removes but not the others as our current "upgrade" becomes
less and less useful.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
a second step wont try to save qt5-default by
installing qtbase5-gles-dev (just to then figure out that gles-dev
breaks qt5-default, so it has to remove the later anyhow).
Thanks for looking into this: That seems like a simpler and less
controversial example than the one I used for the last big ro
the two causes your users to experience the worst of both worlds:
The packages can not be co-installed forcing them through the change in
one sitting and they are an upgrade nightmare as there will always be
one more situation in which apt (or another resolver, or even a human)
decides tha
ists in aptitude – more than 16y later…).
So don't worry that you haven't heard about it yet: You are not the last
one to know, you are in fact well ahead of the curve. 😉
As said, if you have questions (or ideas), feel free to praise the cow
^Ŵ^W^W join #debian-apt on IRC, mail us at
s isn't fixable for bullseye though as such
a change would likely not get a freeze exception.
Best regards
David Kalnischkies
¹ ; char const * const name = "World"
; printf("Hello %s!", name)
(that style reminds me of some other language I have seen but can't
ave the reverse. Fun fact: having it only on one side actually gives
the one having it a scoring advantage in apts conflict resolution, so
for apt it reads in fact like -gles is the preferred package of the
two making it less likely that apt holds back libqt5gui5. In practice
other score points sho
It isn't what you meant to say of course, but you would be surprised how often
that style is used rather than the intended "I have no idea why APT does that
here, could someone please explain it?".
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
?
I would hence ask you to explain a bit better why you think APT is wrong
and provide an example which actually shows these characteristics.
Otherwise I will apparently be a tiny bit annoyed by this thread.
Best regards
David Kalnischkies
P.S.: For these cases -o Debug::pkgDepCache::AutoInstal
ht need to be applied so that this happens only to
packages which end up in Debians repositories… which could complicate
reproducibility as its clear for a buildd, but my local sbuild…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
x27; and you probably
don't want to know why and just accept it as meaning empty list)
Now, suggesting that apt is not an integral part of a Debian system and
could henceforth be removed is of course heresy! The only thing saving
you vile heretics is apts heavy involvement in the creation of these
chroots.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
hat feature via the config option APT::Sources::With, the commandline
flag is just syntactic sugar.
So, as aptitude has I think -o you could e.g. say
-o APT::Sources::With::=/path/to/file.deb
or if all else fails a config file of course.
Best regards
David Kalnischkies
signature.asc
Descr
is now writing a Sources file? Also, --with-source actually
allows to add Packages/Sources files as well, I use them for
simulations only, but in theory they should work "for real", too.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
7;s
As an example, the current plan is to make the switch over for Suite
changes automatic – if some preconditions are satisfied. The discussion
about that isn't hard to find, but here you go: #931566. You are welcome
to add any good ideas not already present (that hopefully shows also
that t
e "apt update" (it will ask an interactive question) or
"apt-get update --allow-releaseinfo-change" (see apt-get manpage) or
[least preferred option] set the config option
Acquire::AllowReleaseInfoChange for basically any apt-based client.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
stion as that seems wrong (and why I put "bug" in quotes).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
he only tool capable of producing an
archive and most of these tools have a focused upstream… the apt client
needed a server to start rolling, but nowadays this server side hustle
is more a brake than an accelerator.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
t really gained anything by it. We
just (literally) moved the problem.
(The other aspects I will hopefully answer with another mail in the
gsoc/outreach subthread)
Best regards
David Kalnischkies
[0] https://wiki.debian.org/Teams/Dpkg/RoadMap
signature.asc
Description: PGP signature
performing the daunting task of actually switching code,
documentation and existing databases over on the other hand… I at least
don't see me enthusiastically raising my arm crying "let me, let me, …".
Best regards
David Kalnischkies
¹ The Census has a field for "Archiv
ensive takes off. SCNR)
> I second this patch. I suggest we add it as section 3.1.1, i.e., as a
> subsection to 3.1 "The package name".
[As this is the first subsection I wonder if there will soon be many
more "rip-off" naming conventions added like python-*, *-perl
sounding like "that guy", but reading the
release notes helps preventing "decades-old" as that includes the
suggestion to run 'clean' before the upgrade and Debian releases a
few times within a decade… (heck, apt hasn't reached the "decades"
milestone yet… so technically… but just a few more months).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ut apt in person.
Best regards
David Kalnischkies
[0] https://wiki.ubuntu.com/AptElfDebugSymbols
signature.asc
Description: PGP signature
ll-recommends.
I would recommend not to recommend it because apt follows the general
recommendation of not recommending the installation of recommendations
of build-dependencies by default for all recommended Debian releases.
Recommended summary: Already the default since 2011.
Recommending eve
On Wed, Feb 22, 2017 at 09:04:16PM +0100, Luca Capello wrote:
> On Wed, 22 Feb 2017 13:16:27 +0100, David Kalnischkies wrote:
> > On Wed, Feb 22, 2017 at 01:06:24PM +1300, martin f krafft wrote:
> > > What am I not understanding right here? Shouldn't "apt-get upgrade
ages failing a cat-picture test!)
Oh, and of course the standard reply: You know, apt does print
a proposal not an EULA – so you don't have to press 'yes' without
reading.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
rs from the fellowship of the cow!
Best regards
David Kalnischkies
[0] https://qa.debian.org/cgi-bin/bugs-by-source
signature.asc
Description: PGP signature
th the API before and I haven't).
And I would still like to have some for a-t-tor, too. The package is
even way smaller than even the smallest node packages [SCNR] nowadays
and someone with an eye for detail, integration and documentation could
do wonders… but I start to digress.
Best regards
David Kalnischkies
[0] https://xkcd.com/1172/
signature.asc
Description: PGP signature
any package M-A:allowed as long as you haven't
got a bugreport telling you it would be nice from some cross-folks (be
it grader, builder, bootstrapper, …). Reason is that M-A:same/foreign is
instantly useable/ful, but M-A:allowed is useless if nothing ends up
depending on it with :any.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
en't looked
closely, but that smells wrong… What are you trying to express here?
(and have you heard that automatic debug packages are a thing nowadays?)
Best regards
David Kalnischkies
[0] https://wiki.ubuntu.com/MultiarchSpec
[1] There are ways around it. See the "If it helps" remark for a hint.
signature.asc
Description: PGP signature
On Thu, Oct 27, 2016 at 10:05:56PM +0200, Tollef Fog Heen wrote:
> ]] David Kalnischkies
> > I would kinda like to avoid encoding the entire answer and sending that
> > in for display because it would be a lot of noise (and bugreporters will
> > truncate it if it is too long
uvmGgCA==
I would kinda like to avoid encoding the entire answer and sending that
in for display because it would be a lot of noise (and bugreporters will
truncate it if it is too long trying to be helpful), so if people who
actually know what they would need to deal with issues (I don't) would
de
d we could implement an opportunistic use
of https if a-t-https is installed and "_https._tcp." srv-lookups get
a favorable response by letting http ask for that first and internally
redirect in that case.
So, you see, as usually, there isn't a shortage on ideas. If someone
wants to wor
t we have all been
waiting for because it isn't. Various people have said for various teams
already which technical challenges need to be solved before we can
seriously think about rolling out https on a broad scale and as usual
the problems aren't fixing themselves if only we talk long enough about
them…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
gs they (and
anything else trying to do security) have I bet the security team would
be overjoyed if all clients talking to a mirror would embed such code…
Best regards
David Kalnischkies
¹ overloaded term, here it means: "Debian Signature Algorithm" – SCNR
signature.asc
Description: PGP signature
loat" and "maintainance" problem is left as an
exercise to the reader.
Best regards
David Kalnischkies
P.S.: There are various arguments why -https is in terms of mirrors – as
their content is static and public knowledge – more an obfuscation
rather than 'real' securit
ch).
Not sure what tool you are using to generate an apt repository, but it
seems rather non-standard given that it includes the deb file also in
the Release file… using one of the many already existent solutions might
be better…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
if the later, does OR exist as | then?, is
it a versioned relation, keeping API and/or ABI, what if v2 of a package
adds/modifies/removes the field, interaction with autoremove………
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
apt(-get) is by far not the only thing
dealing with packages.
For Multi-Arch itself I managed to hide away most of it behind implicit
dependency relations, versioned provides and 'strange' virtual packages
for the libapt-based ones which made that transition quite "easy" all
things considered, but we can't pretend it will always be that "easy"…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
mething more like
"too weak hash" – but error is error either way, so you may want to talk
to the repository maintainers (there are more than just this repository
with such an issue) and I should write a patch to produce a better
message as we were talking in the APT team about it for a whil
t;He that is of a proud heart stirreth up strife: but …".
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
On Thu, Dec 24, 2015 at 01:50:45AM +0100, Alberto Salvia Novella wrote:
> Luis Felipe Tabera Alonso:
> David Kalnischkies:
> > It is not a good idea to perform autoremoves unattended for situations
> > in which you have installed A (gui) depends B (console) depends
> > C
ve still ideas which look good on paper only… and its good that
others put a stop to such ideas before those ideas have a chance to hurt
me (and I can assure you, I implemented ideas which never should have
been and now taunt me by their mere existence).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
(adding the missing reference to online resources)
On Tue, Dec 08, 2015 at 01:35:59PM +0100, David Kalnischkies wrote:
> messups without hashsums and pdiffs currently haven't [0], but if we
[0] https://lists.debian.org/debian-dak/2015/08/msg00012.html and my
followup https://lists.de
On Tue, Dec 08, 2015 at 09:16:33AM +0100, Vincent Danjean wrote:
> Le 06/12/2015 13:01, David Kalnischkies a écrit :
> > On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote:
> >> Will it still be possible to update just the apt-file index, separately
> >> fro
On Sun, Dec 06, 2015 at 08:50:55AM -0500, The Wanderer wrote:
> On 2015-12-06 at 07:01, David Kalnischkies wrote:
> > On Sat, Dec 05, 2015 at 07:58:07AM -0500, The Wanderer wrote:
> > (as I am sightly lying, it is actually possible – just not very
> > accessible for a user and
On Tue, Dec 08, 2015 at 10:32:52AM +0100, Tollef Fog Heen wrote:
> ]] Marvin Renich
> > * Tollef Fog Heen [151207 00:17]:
> > > ]] David Kalnischkies
> > > > [And before someone complains about PDiff being slow in apt based on
> > > > some years old
er you prefer and use something different a second later.
And for that matter: Running any "update"-like operation with aptitude,
synaptics or any other libapt-based front-end is beside the display
pretty much the same code as well (and the exact same data), so they
will get all the
way would be to choose a new 'best hit', if either
> * there is a target release and it matches the release of the package,
> * or there is no target release
> and the version is higher than the last best hit.
>
> Attached is a patch fixing this and another
o complain…
Anyway, a giant list of things which could potentially be done isn't
going to change anything as the problem isn't that we have too few tasks
for the giant contributor armies working on the tools which need to be
changed for something to happen…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
1 - 100 of 239 matches
Mail list logo
