gh it feels a bit wrong and
remembers me of my dream from above. ;)
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/z2rc64043e61004090453r371cdeb9xdee967f396a39...@mail.gmail.com
is isn't a complete solve - as far as i understand multiple packages could
replace different files in a package causing it to disappear - but it would
enhance the simple normal package rename case a bit.
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
--
To UNSUBSCRIBE, em
Hello (again),
2010/4/10 Jonathan Nieder :
> David Kalnischkies wrote:
>> he needs to install git-core which he does again after noticing that it
>> doesn't work at the first try and face a conflict resolution process now…
>> (or he had git already installed through so
t the
version merger to work correctly which is why i asked if the policy
output is complete…
Best regards / Mit freundlichen Grüßen
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/p2yc64043e61004300356za77e0adeie1a4b256808a3...@mail.gmail.com
ammer
and ignore for the hash all colons and zeros in the string.
At least it is better than ignoring the versions completely and
writing a full-blown version number normalizer just for this small
use case seems to be over-engineering…
Best regards,
David Kalnischkies
--
To UNSUBSCRIBE
t-get call - an example:
>>>>>
The following packages disappeared from your system as
all files have been overwritten by other packages:
apt dpkg
Note: This is done automatic and on purpose by dpkg.
<<<<<
* (hint hint)
2010/4/10 David Kalnischkies :
> b) a) + ove
at is also the reason why the Note is displayed always
at the end to ensure that the user does not worry to much.
I should have added that the Note will disappear (haha)
if -q is given while the list is a bit more resistant
(as all other lists) and reacts only on -qq.
> 2010/4/10 David Kaln
ms to
be the follow up packages of oldPkg. awk on the other hand seems to be
just still a depends to be able to execute maintainerscripts successful.
Nothing implicit
Best regards,
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktik4n7dbdcbvqbmeaujudyzprbw0zc729bqay...@mail.gmail.com
ignore :amd64 and configure :i386
- choose both, fail :amd64 as already configured (and maybe configure i386)
- fail as not specific enough
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe&quo
es in the same context
b) requiring different inputs based on the M-A state asks for confusion
c) breaking release upgrades should be avoided
Best regards
David Kalnischkies
P.S.: Thanks Raphael for the forward/reminder on deity. I intended to
send that way earlier, but forgot about it after wri
architecture is disappearing, but there are no
Replaces (not even implicit) in place to allow that and the implicit
Conflicts wouldn't allow a seamless disappearing anyway.
So implementing this sounds for me a bit like black voodoo…
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to
On Mon, Dec 12, 2011 at 14:37, Raphael Hertzog wrote:
> On Mon, 12 Dec 2011, David Kalnischkies wrote:
>> You talk only about output, but the title is "I/O" and i think it's unlikely
>> that dpkg has a different understanding of pkgname in output vs input,
>> s
On Tue, Dec 13, 2011 at 20:55, Julian Andres Klode wrote:
> On Tue, Dec 13, 2011 at 09:19:55AM +0100, Guillem Jover wrote:
>> On Mon, 2011-12-12 at 18:14:15 +0100, David Kalnischkies wrote:
>> > Beside that i wonder which --force flag this should be, given that it
>> >
On Tue, Dec 13, 2011 at 08:29, Guillem Jover wrote:
> On Mon, 2011-12-12 at 18:15:12 +0100, David Kalnischkies wrote:
>> dpkg --remove libc6 # removing libc6:i386 and libc6:amd64
>> ?
>
>> Users will "love" you for this, given that it is completely inconsi
flicts - and
is this way very simple. If we find later some more clever way to avoid
the need to explicitly remove the other architecture, fine. We can change
APT then, until then it will just work this way in most cases and cries
loudly in the essential-case. I just think that we don't need to de
want to have a look at it.
I think we had a similar "issue" with explicit mentioning of the zero
epoch in the past.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listma
the interpretation of 'pkg' in dpkg in any way.
It can't hurt and should be the easiest to implement…
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@l
he impression it would be good to have an option in dpkg
to tell dpkg what it should consider as "native" architecture similar to
APT::Architecture to easily solve these kind of communication problems.
Best regards
David Kalnischkies
P.S.: Yes, this was started as a bugreport, but hal
lse in this multiarch-discussion was hinted that we could
sync on the version in (optional) Source tag instead to allow binNMU.
It's a bit too late (in my timezone) for me to do serious predictions on
difficult-levels on changing this in APT but i guess its relatively easy.
(the only problem i
On Thu, Feb 16, 2012 at 23:10, Carsten Hey wrote:
> * David Kalnischkies [2012-02-16 03:59 +0100]:
>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>> >>> it needs to find and remove foo:*
>
> foo:all (or foo:any) instead of foo:* would save the need to
On Fri, Feb 17, 2012 at 15:46, Jonathan Nieder wrote:
> David Kalnischkies wrote:
>
>> You generously left out the paragraph describing how APT should
>> detect that the package foo is in fact a library and not, say, a
>> plugin, a dev-package, a dbg-package or a fut
On Fri, Feb 17, 2012 at 19:53, Carsten Hey wrote:
> * David Kalnischkies [2012-02-17 14:15 +0100]:
>> You generously left out the paragraph describing how APT should
>> detect that the package foo is in fact a library ...
>
> My impression was that you think very library cent
never migrate to
testing even through it is available for at least some archs
(or specifically: not available for i386), so you either have to hack
with [arch] or make it any, both is bad…)
See also [0] and [1] in the MultiArch spec which talk about this and
a related i
dependency
is unsatisfied (same problem with depends if no architecture is specified).
Shouldn't provides be limited by the architecture their provider can work on?
Or did I miss something here?
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
On Mon, Jul 9, 2012 at 2:34 PM, Jonathan Nieder wrote:
> David Kalnischkies wrote:
>> while playing around with the APT code regarding architecture-specific
>> dependencies I stumbled over the handling of Provides in that context:
>>
>> Package: pkga
>
On Fri, Jul 13, 2012 at 11:36 PM, Jonathan Nieder wrote:
> David Kalnischkies wrote:
>> As an example:
>> I highly doubt "phonon:amd64" with a dependency on "phonon-backend" will
>> work with "phonon-backend-vlc:armel" which provides "ph
be satisfied by virtual
> packages.
My 'believe' is that in this example:
Package: foobar
Architecture: amd64
Depends: package-bar
that last line is in fact read as:
Depends: package-bar:amd64
So it would make sense to handle implicit or explicit specific-arch
depende
e we need to clone this to aptitude (as it does some direct dpkg
calling on its own as far as I know) and whatever other dpkg front-end assumed
that it could arch-qualify everything in a multi-arch universe.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists
On Mon, Sep 3, 2012 at 9:05 PM, Guillem Jover wrote:
> On Mon, 2012-09-03 at 13:53:47 +0200, David Kalnischkies wrote:
>> On Fri, Aug 31, 2012 at 5:26 PM, Guillem Jover wrote:
>> > So it would seem to me the arch-qualifying logic in apt is not right,
>> > it rea
p://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463030
A "graceful" kill happens on SIGINT in apt/wheezy in the sense that we will
let dpkg finish whatever it does current (which can be quiet a lot) and stop
after that.
Best regards
David Kalnischkies
P.S.: I don't see why
quiet what the package without ~ would be. Not sure if
this is the right association for other future usecases though.
I can't really imagine a good reason to have such dependencies though, as
packages build with profiles are supposed to go away after bootstrap, aren't
they? And if you take profiles to far e.g. like with different libc's, you
basically have created a new architecture…
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_faqshx6yewt2qzq9xejjjcqzyb5umt18xhrwf--i8o...@mail.gmail.com
iles for
> embedded builds. For example this way binary packages for emdebian grip or
> crush could be directly generated from debian proper source packages. Maybe
> there exist binary packages specific to only emdebian that then should depend
> on the emdebian version of other
On Sun, Apr 28, 2013 at 4:40 PM, Johannes Schauer wrote:
> Quoting David Kalnischkies (2013-04-28 14:27:12)
>> On Tue, Apr 23, 2013 at 9:15 PM, Johannes Schauer wrote:
>> My answer: X=~ and Y=. (or anything else expect : really)
>> As this is something you will have potenti
Hi * !
(hopefully quoting enough for dpkg list to get the context)
On Fri, May 16, 2014 at 12:57:27AM +0200, Aurelien Jarno wrote:
> On Mon, May 12, 2014 at 09:03:50PM +0200, David Kalnischkies wrote:
> > On Tue, May 06, 2014 at 11:22:00PM +0200, Aurelien Jarno wrote:
> | # apt-cach
I hope to have some time after jessie release to look into this as its
kinda embarrassing that I wanted to do it for 5 years now…)
Anyway, we can't enable this option retroactively even if we wanted to…
Best regards
David Kalnischkies
¹ so basically, it would do what my suggestion is above to b
the previous mail was that the last
command here would fail as a pending trigger can't be run. It doesn't,
so my biggest concern with dpkg::TriggersPending isn't really existing,
but I still think that running it all the time isn't needed if we can
just do the more general ConfigurePending once.
Best regards
David Kalnischkies
P.S.: I will respond to other parts of the mail/thread in other
threads/bugs to keep all reasonably ordered… if that is possible.
signature.asc
Description: Digital signature
this is effectively increasing the amount of micromanaging
I have to perform as I have to keep track of the status of the orders of
the day now as well…
Best regards
David Kalnischkies
¹ On an intellectual level I have the same issue with all --pending
operations, just that apt is described as
;t really over for me and given that we disagree on the
first line everything else hopefully just follows suite (or at least
makes a bit more sense).
> On Sun, 2014-11-23 at 18:40:32 +0100, David Kalnischkies wrote:
> > On Sat, Nov 15, 2014 at 06:24:16PM +0100, Guillem Jover wrote:
> &g
interpreting it might exist
until my nose got rubbed in it yesterday….
So, unable to find supporting evidence for either case in the few
specifications, I am appealing now to the high court of Multi-Arch.
Best regards
David Kalnischkies
¹ referring to apt-get here in particular, but anythin
tion. I do not know how to do similar
> tests with dpkg without needing superuser privileges. Is there a way?
>
> How did you compare apt and dpkg's behaviour in this case in practice?
Discussed off-list as its slightly off-topic here.
But for completeness in short: APT has a battery of shellscripts we
dubbed integration tests, which can among other things build packages
and (try to) install them via apt with dpkg as non-root in a temp
directory.
Best regards
David Kalnischkies
[0]
https://lists.alioth.debian.org/pipermail/multiarch-devel/2014-November/98.html
signature.asc
Description: Digital signature
I understand it also Pietro) have no
> problem with just following what dpkg does. I think it's more important that
> we
> pick one way to interpret these things and implement the same behaviour in all
> tools resolving dependencies now. If these decisions turn out to become
&
retroactively calculate the hashes for already installed
packages to an eternal "chaos" of never being quiet sure if the fields
are available…
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
ou very much for any help.
Cheers,
Thomas
--
To UNSUBSCRIBE, email to deity-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55ca93a5.3030...@gmail.com
- End forwarded message -
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
(usually)
if you use the (bigger) Conflicts hammer as the file you want to
override is already gone…
--
I have still some cleanup/testing to do and I am better at mis-
interpreting and criticising than writing documentation, so I will
refrain from suggesting other wordings for now – also to not blow
up the mail length further.
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
appily accept any patch flying my way
implementing architecture wildcards differently if need be, but I am not
going to do it myself mainly because I expect that to have fallout – not
in apt, but in things using apt – and I don't have the energy (or the
rights) to deal with such things efficiently.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
check-files-ownership
> imagemagick:all
> /usr/share/doc/imagemagick/www/api/MagickCore/utility-private_8h_source.html
> │ ├─dpkg-query -L imagemagick:all
> │ └─grep -F -q -x
> /usr/share/doc/imagemagick/www/api/MagickCore/utility-private_8h_source.html
Well, that looks like a maintainerscript running amok as apt doesn't
call dpkg-query. As that loop seems to be produced by
dpkg-maintscript-helper itself, reassigning to dpkg (and keeping
a clone), but perhaps its also imagemagick calling it wrong as
imagemagick is only newly 'all', it used to be 'any'…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
it… I wanna
draw attention to the --keyring option of your debootstrap command.
debian-user or perhaps the porters would be a better place to ask (and
if only because of a quicker reply) such a question through as this
question isn't related to dpkg development…
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
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
gtracker isn't
the place to discuss this – nor is my existance exorbitantly interested in
'chairing' such a discussion at the moment as there are other things
I should be working on, which is also why I only think in private that
this might be a topic which should end up on d-d@ as it effects at least
the big virtual packages.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
self: I haven't looked closely, but apt tries
to not explore solutions caused by M-A:same version screw – aptitude
seems way more willing to suggest such solutions; that is okay I guess
as it is way more interactive, too.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ecursive invocation style
dpkg::install::recursive "false";
dpkg::install::recursive::force "true";
So, lets let everyone pick his/her preferred poison and we will see who
dies last in this vote… (cc'ed dpkg as they are as involved in it as apt
is).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ts involving dpkg output is harder for preciously the initial
problem). It isn't really targeted for usage by the general public…
(Althrough we had it thankfully for the public as temporary workaround
at the time pseudo terminal handling ran hovac in the small differences
between linux and kf
Hello everyone,
First of all an apology for the late response from the APT Team side,
but Michael Vogt is currently a bit busy with work, family stuff and
advising and helping me, so the intern discussion last a bit longer
and i don't want to enter the discussion with my half baked ideas. ;)
Seco
ome graphical package viewer would be very strange
and completely unexpected).
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
general, so I would say this isn't an apt bug.
(Althrough, if we decide on v2, I guess apt needs to change anyhow as
that same call thing might be just dumb luck in this case. Not even sure
if v1 is in any way "guaranteed" to be perfectly honest…)
Can't stop the feeling that we had issues with python begin called from
prerm before and the general advice was: "don't – stick to essential".
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
his.
I intend to follow as apt might color more of its output someday and
would eventually run into the same problems then.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
quirement of the least external dependencies possible).
I fear though that we will find at least one user for every feature
gnupg currently has, but wrapped in an interface which doesn't lend
itself very well to automation and/or additional wrapping.
So this could end up being a colossal undertaking…
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
s are no problem and the chroot hopefully ends
up with the keyring package(s) it needs? (Anyway, different topic)
Best regards
David Kalnischkies
[0] If I ever get back to
https://salsa.debian.org/apt-team/apt/merge_requests/33
the answer to which keyring is in the trusted set becomes a lot harder
On Thu, Feb 06, 2020 at 08:00:26PM +0100, Johannes Schauer wrote:
> Quoting David Kalnischkies (2020-02-06 16:43:22)
> > On Thu, Feb 06, 2020 at 03:28:28PM +0100, Johannes Schauer wrote:
> > >"I have a keyring I know that I want to use (like
> > >/u
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
mostly based on M-A more or less silently adding architecture
specific dependencies and not a whole lot of things cared too much.
Or its just because they aren't used a whole lot for reasons.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
ention of it on the list) and given that this is something that
"just" works with Docker.
As explained in the other bug, there is no veto and as you can see its
easy to completely ignore me (and anyone else) but I wanted to say it
anyhow, so that nobody is surprised later on.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
63 matches
Mail list logo
