Re: APT hosed, segving in libapt-pkg-libc6.9-6.so.4.8.1
Hi Frans Pop & debian-devel, > Thanks! David Kalnischkies and I were able to reproduce a crash for > sources that had no Packages file. This is fixed with the 0.7.23.1 For anybody further interested in the bug: Something like a index-out-of-bounce, but libapt didn't access the end (this was checked!) it only iterates over the end... sorry my bad. On Fri, Aug 28, 2009 at 18:34, Frans Pop wrote: > Michael Vogt wrote: >> It looks like this is releated to the new code that adds lzma support >> for Package file downloads and the option to configure in what order >> the compression types should be used. [...] > announcing the new config option (including an example maybe), and also > mentioning the new preference order? See: man 5 apt.conf -> THE ACQUIRE GROUP -> CompressionTypes The description is far from being perfect and a few things are missing so real world input is highly welcomed. Addition: The order is defined by insertion into the list and missing default methods will be added automatically at runtime, so everything you need to do to prefer gzip over bzip2 and lzma would be: Acquire::CompressionTypes::gz gzip; NEWS entry> I thought it is more a power user option and as it changes nothing to the default so imo not fit for an entry, but after cleaning up the documentation on this option we will announce it as an aside in an upcoming NEWS entry, i guess. Best regards / Mit freundlichen Grüßen, David "DonKult" Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: APT hosed, segving in libapt-pkg-libc6.9-6.so.4.8.1
> I looked in /usr/share/doc/apt/examples/configure-index.gz first, but I
> could not find it there. Should it be added?
Yes, it should be. A few others seems to be missing also...
Will be added in the next upload round.
>> The description is far from being perfect and a few things are missing
>> so real world input is highly welcomed.
> The example currently only shows how to set the first compression type.
> An example that also sets a second fallback would be nice.
[...]
>> Addition: The order is defined by insertion into the list and missing
> Inserted before or after current value(s)?
Yeah, this is one of the thinks a bit harder to understand,
and the documentation definitely lacks a proper explanation for this.
The list which apt uses per default would look like in the config file:
Acquire::CompressionTypes::bz bzip2;
Acquire::CompressionTypes::lzma lzma;
Acquire::CompressionTypes::gz gzip;
or (which is better to understand in my eyes):
Acquire::CompressionTypes {
bz bzip2;
lzma lzma;
gz gzip;
};
So in short: Acquire::CompressionTypes is an associative fifo list which
ensures that it has always at least the three default entries.
(Exception: Entries are removed because their binaries are not in place)
> Would the following also work to use an *un*compressed packages file:
> Acquire::CompressionTypes::"" "";
A quick test suggest that this would work as a hack, but apt doesn't like
uncompressed files and will print many false-negative Ignore messages.
Debian doesn't provide an uncompressed file (main sid i368 would be ~28 MB)
and if i am remember correctly apt doesn't even try to acquire uncompressed
files (expect for local archives with the method file of course) per default.
> That's what I did, and it works great! I got a very notable speed
> improvement on my sparc box, and expect even better results for my s390
[...]
> I think it's worth mentioning, especially if you could also mention, as an
> example, that using gzip can improve speed on slower systems.
Really? Never thought that there is a noticeable difference between the
two compression types if you add the increased downloadtime to gzip,
but i never tried/measured it... will be added to the news sidenote.
Thanks for the suggestions!
Best regards / Mit freundlichen Grüßen,
David "DonKult" Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: APT do not work with Squid as a proxy because of pipelining default
Hi all, i don't want to interrupt your battles so feel free to ignore me, but i want to raise some questions (for you and me) none the less: The notice about the - in the eyes of the writer of this manpage section - broken squid version 2.0.2 in the apt.conf manpage was changed the last time in 2004, so the issue isn't "new". The manpage at least claims that this squid version is broken also in respect to other cache control settings. I don't know a single bit about squid but a search for "squid pipeline" turns up some documentation about a pipeline_prefetch setting: > Available in: 3.12.73.HEAD2.HEAD3.02.6 > > To boost the performance of pipelined requests to closer > match that of a non-proxied environment Squid can try to fetch > up to two requests in parallel from a pipeline. http://www.squid-cache.org/Doc/config/pipeline_prefetch/ For somebody without knowledge this looks like as any version in debian should be able to handle a pipeline - otherwise this setting wouldn't make much sense… The default value for the APT option above is btw 10 and in apt #413324 we have a claim that squid works well with a value of 5 or even 8 -- so it is maybe "just" a bug in handling "too much" pipelined requests? Or something comparable to what happened in #541428 regarding lighttpd and pipelining (timeout)? (i am just shooting into the dark) Also, then we talk here about pipelines and her usage keep in mind that APTs http usage is special compared to an implementation and usage in a browser: We have a trust chain available so we should be on the save side security wise, the number of debian archives is limited and most of them should be on a sane webserver (if not i would not have much trust in the archive…) and especially on "apt-get update" we have either a lot of cache hits (file has not changed) or a lot of very small files (Release, Index and maybe pdiff) to transfer. New package updates come from the same archive most of time and most packages are relatively small, too, but having an upgrade including at least 500 packages is relatively common… On the other hand APTs http client isn't as nice as he could be in terms that he could fallback to non-pipeline, retry or whatever. (and i wouldn't be too surprised if this would turn out to be an APT bug) As we all know APT is a debian native tool and the base of a whole bunch of other stuff so beside ranting about his shortcomings we could also work on patches as the people with enough knowledge to do this seems to be already around in this thread. Thanks in advance and best regards, David Kalnischkies P.S. Sry Luigi Gangitano for cc'ing, but i don't know if you follow the thread and i included too often "squid" in the mail to not direct the mail into your direction. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinq0j1fd78p200qihsq5ctv3qmbwd8srxgje...@mail.gmail.com
Re: Looking for maintainers of Spacewalk packages
Am 28. Mai 2010 06:08:43 UTC+2 schrieb Miroslav Suchý : > BTW: our plan for summer, is to develop plugin for apt-get which allows you > to download packages from Spacewalk server directly using apt-get. That is > last missing piece for declaring support for Debian as complete. Feel free to join de...@lists.d.o for discussions/questions about APT. :) http://lists.debian.org/deity/ Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktil7jbbjexjzheqy2hkxduvv3m5glnevcb6ru...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/28 Stephen Leake : > Ludovic Brenta writes: > >> Stephen Leake wrote: >>> Ludovic Brenta writes: >>>> The reason for all this is that when a package libX2-dev Conflicts: >> with >>>> and Replaces: a package libX1-dev, aptitude does not remove libX1-dev >>>> and install libX2-dev; instead, it marks libX1-dev as broken and leaves >>>> libX2-dev uninstalled. >>> >>> This seems like a clear bug in aptitude. This seems like a bug in your understanding, not in apt(itude). The name libX1-dev suggests that it can be co-installed with libX2-dev and co as otherwise the version number wouldn't make much sense (yeah i know, in a few other cases… i said not much) - automatic updates in which libX1-dev is killed for good by libX2-dev is absolutely not what i would expect as packages will (build-)depend on libX1-dev which obviously can not be satisfied by libX2-dev -- if it could it would be called libX1-dev also or even libX-dev and only the real library is called libX2 … 2010/5/28 Stephen Leake : > But it seems the best way to reduce the annoyance is to improve aptitude > (or dpkg). Add an option that says "treat Replaces as the correct > upgrade path". Or add a new control field Upgrades for that purpose. Replaces form the correct upgrade path? I really thing Depends form the upgrade path - and all the negative ones just make it more complicated. ;) (or more serious: give additional hints) Negative Dependencies have a serious problem: A package manager can choose to retreat from upgrading a package because it would e.g. break to much - and that is in your interest! But do not only shoot into the dark, each manager has debugoptions to show you why it does certain things. Looking at these decisions can help a lot in understand how to express dependencies ((pre)depends, recommends, suggests, replaces, conflicts, provides, breaks, …) correctly (or it will lead you into insanity, depending on how pain resistant you are ;) ). > However, my reading of Debian policy gave me the impression that > Replaces was supposed to be used for that purpose. Since the tools > currently do not fully support that use, I think they are broken. No. Replaces is used to say to dpkg: It is okay that this package overrides files of the other package - otherwise dpkg would complain loudly for good reasons. It doesn't say something about the upgrade path. It also does not say that B will replaces A completely - this is maybe the case, maybe not (it replaces only a single file). Provides give the indication that B is a complete replacement for A, but in this case you should be sure that it is really a complete replacement. libX2-dev can't provide libX1-dev for example - or it could but only if all packages which work with libX1-dev can be built without a change with libX2-dev instead of libX1-dev. This also eliminates the idea to let libX1-dev be a dummy package only depending on libX2-dev as the packages building against libX1-dev will be (completely) broken. This is normally done for Package renames and described in e.g. http://wiki.debian.org/Renaming_a_Package Method B will in future (squeeze+1) take care of these dummy empty packages if the maintainer does it correct. Until then we need to handle them with autoremove and co - which is yet another "interesting" and complicated problem… So i would recommend to describe more what you actually want and your specific problem so people can help you (maybe the questions are a better fit in d-mentors) and not what you think is a bug in a package manager - if it is really a bug it should be expressed with a proper bugreport against the package manager in question… Best regards, David Kalnischkies (Debian APT GSoC student) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik96wdwal1imqqkm_fzkqyfb0vnsdnb6ywmp...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/29 Ludovic Brenta : > David Kalnischkies writes: >> No. Replaces is used to say to dpkg: It is okay that this package >> overrides files of the other package - otherwise dpkg would complain >> loudly for good reasons. It doesn't say something about the >> upgrade path. > > I disagree with this particular part of your analysis. What you say is > true of Conflicts, not of Replaces. IMHO, Replaces really, clearly > suggests an upgrade path. Why else would the package renaming procedure > require both Conflicts and Replaces? Consider a package A which moved from a bad example-config file to a full blown doc translated to 100 languages. The documentation is split out into a new package A-doc which will Replaces the old A version as it will override the "old" example-file. The A-doc package will end up as a Recommends or Suggests for A as it is not strictly needed to work with A. Should a package manager really follow the Replaces? This would mean we could end up removing A because A-doc replaces it? Or get full blown documentation - now that you have used the application for years without looking at the (non existing) documentation so far… You can construct for Conflicts a similar (and better) situation, 'extra' packages for example can Conflicts/Replaces with each other without any problems… Both together doesn't indicate much as well: Your installed mail-transport-agent conflicts+replaces all other MTAs. Is installing exim4 instead of postfix really an upgrade path? > Let me emphasize again that, for Ada, a new version of a -dev package > (i.e. libX2-dev) is *not* a complete replacement for libX1-dev, > therefore we must use neither a dummy transitional package nor a > Provides relationship. The question is why you want that people which have libX1-dev installed need to upgrade to libX2-dev AND remove libX1-dev by describing that only with dependencies in libX2-dev. It is simply not possible and doesn't make much sense: If libX1-dev can't be used anymore the package breaking it should "Breaks" it. If it is not broken why removing it? It will be autoremoved if it is not needed anymore… libX2-dev will be installed then something depends on it - or if the user needs it and requests it manually. I also don't see why libX1-dev and libX2-dev have Conflicts and/or Replaces on each other. Their naming _highly_ suggests that they can be co-installed and used. If they can't be co-installed and used why is the package not called libX-dev instead… Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimyqurbfoka7n_dye0tfiytnmjrkpue9fxi1...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/30 Ludovic Brenta : > David Kalnischkies writes: >> 2010/5/29 Ludovic Brenta : >>> David Kalnischkies writes: >>>> No. Replaces is used to say to dpkg: It is okay that this package >>>> overrides files of the other package - otherwise dpkg would complain >>>> loudly for good reasons. It doesn't say something about the >>>> upgrade path. >>> >>> I disagree with this particular part of your analysis. What you say is >>> true of Conflicts, not of Replaces. IMHO, Replaces really, clearly >>> suggests an upgrade path. Why else would the package renaming procedure >>> require both Conflicts and Replaces? >> >> Consider a package A which moved from a bad example-config file to >> a full blown doc translated to 100 languages. The documentation is split >> out into a new package A-doc which will Replaces the old A version >> as it will override the "old" example-file. The A-doc package will end up as >> a Recommends or Suggests for A as it is not strictly needed to work with A. > > This example is wrong. (I thought of this one while writing it but want to be a bit more generic:) apt currently Replaces manpages-pl because it includes now the polish translation of its manpages itself. Is apt with this Replaces now a valid upgrade path for manpages-pl? Even (or especially) if only manpages-pl is installed on the user system? The Replaces says that if i upgrade apt i should at least try to upgrade manpages-pl before (if it is installed) to get right of the Replaces - it doesn't say that if i have manpages-pl installed i should install apt now as well as it doesn't say that i should install manpages-pl if i have apt installed. If i want that i need a Depends… > The consequence is that, despite the fact that these packages are broken > (without the need for a Breaks: in their successor packages, BTW), > aptitude prefers to leave them installed rather than remove them; this > in turn blocks upgrades. If aptitude hasn't changed its complete logic recently it will behave as apt and will never allow a user to move from a consistent into an inconsistent state, so either your words are misleading, i don't understand you or both. A package is not broken out of a sudden for a package manager. Either the install candidate of another package Breaks it, Conflicts with it or its dependencies in the candidate version are not satisfiable. A in this way "broken" package* is either kept (by not installing the other packages), upgraded (if dependencies allow it) or removed (if installing the other packages is considered more important than the install status of this package) These options are present and a package manager will chose one of those depending on how costly they are. If the remove of package A causes e.g. the remove of thousand other packages it is likely that A will be kept back instead. * It is only broken if the package manager would choose to upgrade regardless of the outcome. Its complete unrelated if the functionality of the package is broken. This can happen, and this need to be modeled with dependencies (Breaks and to a lesser extend Conflicts is what you want) as otherwise the package manager will not know about it. It (=the manager) can't follow rules it doesn't know… > and, of course, Depends: on the exact version of A, i.e. > > Package: A-doc > Depends: A (=2) I hope not as it would be broken for all binary non-maintainer uploads of A… And the Depends is at least questionable even without a version number (many *-doc packages don't depend on anything. And if they do the Depends is completely unrelated or extreme relaxed, only a small subset does it like you suggest it). Give it a try yourself: apt-cache show $(apt-cache search ^.*-doc$ --names-only | cut --delimiter=' ' -f 1 | sort -R | head -n 50) | grep -e 'Package: ' -e 'Depends: ' > Please read the Debian Policy for Ada, to which I provided a link (at > least section 3.2 "Ada Library Information files". I mean it. If you > don't then you cannot possibly understand the problem. I don't know anything about Ada and i don't have read the policy for it as i will not understand it because of that - but even if i would read it it doesn't change the dependencies written down - at least as long you haven't told all package managers like dpkg, apt and aptitude to read and understand your policy as well. Thats why i response here, i just want to help you understand what a package manager will do with your dependencies and that is independent from the content of the package. In the end you will need to write dependencies even a crappy piece of code can understand and at least for me it would be an indicator if even humanoid dependency s
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/31 Ludovic Brenta :
> David Kalnischkies wrote:
>> 2010/5/30 Ludovic Brenta :
>>> The consequence is that, despite the fact that these packages are
> broken
>>> (without the need for a Breaks: in their successor packages, BTW),
>>> aptitude prefers to leave them installed rather than remove them; this
>>> in turn blocks upgrades.
>>
>> If aptitude hasn't changed its complete logic recently it will behave as
>> apt and will never allow a user to move from a consistent into an
>> inconsistent state, so either your words are misleading, i don't
>> understand you or both.
>
> I explained in my original post; please re-read it and then you will
> understand. Hint: removal of gnat-4.3.
The only thing i can see from this "hint" is that dependencies are
missing. Fine, i guess i have talked about nothing else so far.
Whatever causes the removal of gnat-4.3 can e.g. also "Breaks"
all the packages who missed proper dependencies before.
>>> Package: A-doc
>>> Depends: A (=2)
>>
>> I hope not as it would be broken for all binary non-maintainer uploads
> of
>> A…
>
> You are correct; I really meant:
>
> Package: A-doc
> Depends: A (=${binary:Version})
If A gets a binNMU 2+b1 this depends will be broken, as A-doc
will not be rebuilt in a binNMU - that was all i meant.
(Assuming that A-doc is a arch:all package and A arch:any)
> package. Of course this is a minority of -doc packages. But my point
> was to disprove your theory that a -doc packages needs to Conflict and
> Replaces with a non-doc packages. It doesn't. Now let's drop that
> part of the discussion.
I talked about "Replaces", not about "Conflict". The Replaces is enough
to suggest an upgrade of the replaced package if possible, but okay,
lets drop it as it is relatively unrelated.
>> Thats why i response here, i
>> just want to help you understand what a package manager will do with
>> your dependencies and that is independent from the content of the
> package.
>>
>> In the end you will need to write dependencies even a crappy piece of
>> code can understand and at least for me it would be an indicator if
>> even humanoid dependency solvers can't understand them…
>>
>> (Also, while a policy is free to declare that white is the new black
>> it is a good idea to follow established rules and just say black.)
>
> If you refuse to read the document, how can you judge what it says?
If it requires changes to all package managers to handle upgrades
in a nice way for this subcategory of packages as it was suggested here
i guess i can say that. I btw didn't say that i mean your/ada policy -
i said "a policy", so if ada policy doesn't change the sense of
dependencies (white to black) i can apply common rules (black)
and everything is fine. It just seems that i can't.
> I think I have narrowed down the crux of the problem to this simple
> question that a dpkg expert like yourself ought to be able to explain
> to me:
dpkg is not my cup of tee, APT is. Anyway:
> What is the difference between Conflicts: and Replaces:?
All dependencies relations are defined in the policy [0],
for Replaces see e.g. [1].
In short: A Replaces only indicates that a file in package B
will be overridden - nothing more (and nothing less).
Just because a package overtakes a >file< doesn't automatically
mean i should install it. (see apt vs manpages-pl).
It absolutely doesn't have the sense of indicating package B
replaces package A completely. This is identical to a package
rename and can be handled as such.
Best regards,
David Kalnischkies
[0] http://www.debian.org/doc/debian-policy/ch-relationships.html
[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktikuolaxcm2kkxhjuhduqjjjoczfjbnystycb...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/5/31 Ludovic Brenta : > Option 1: upload a new package "gnat" that Breaks: all -dev packages > that were present in Lenny but are no longer present in Squeeze. > This however does not really help apt, or the user, discover the > new replacement packages. > > Option 2: change each new -dev package so that it Breaks: its > predecessor. For example, let libgtkada2.14.2-dev Break: > libgtkada2.8.1-dev. As far as i understand can the old lib-packages not be used with the new gnat. Right? If so i would say gnat should Break them. Breaking them in the new-libs will not help as the new-libs still need to be installed to get the Breaks effect - and they are broken before. With the break you can force the update of old-libs, which could depend in their new version on the new-libs. I don't see another route to install the new-libs, but 1. Is this really needed? If the user needs them they are an apt-get install (or similar) away. new-lib isn't a drop-in replacement for old-lib (or?) and (s)he therefore needs to learn a new way anway… 2. the old-libs will stay installed in at least of the form of a transitional package in oldlibs as at least apt/lenny has no support for disappear packages so this trick can't be used (not sure about dpkg, aptitude uses apt facility in this regard, so also no support). The other option is to follow one and only Breaks the old-libs away. This way you get right of the old-libs packages with the expense that new-libs are not installed automatically. > Question 2: if I add Breaks: to a -dev package, which ones of > Conflicts: and Replaces: should I also specify? (currently, both > are specified; the new packages replace almost all files of the > old packages). You want only Breaks or Conflicts. Breaks is in general the nicer Conflict - in some way they are the negative version of Depends and Pre-Depends: Conflicts must be satisfied before the package is unpacked - so both packages can't be in unpack (or higher) at the same time, while Breaks only says that both can't be in installed at the same time. Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikdsnc7bdzyeyf4uqkc9czacnfkvpfsak3bo...@mail.gmail.com
Re: A Look In the Mirror: Attacks on Package Managers
2010/6/6 Joey Hess : > Josselin Mouette wrote: >> It does. If you don’t re-run “apt-get update”, the signature will be >> considered invalid. > > j...@gnu:~/tmp/apt-0.7.26~exp5>grep -i Valid-Until -r . > zsh: exit 2 grep -i Valid-Until -r . > > What'm I missing? Nothing - or at least I didn't know about such a feature until now… (Not impossible, but not very likely ;) ) A quick scan over the open bugreports also doesn't indicate that it was requested so far. Another quick look at non-official archives indicate also that it is NOT commonly used (official debian and security use it, backports not, anyone else?) so this should be propagated more? Third one: reprepro has a ValidFor option to generate this stanza, what about the others? (apt-ftparchive obviously doesn't so far) In regards to APT i will have a look later how to implement it, hints regarding a good error message are welcomed as i can currently only thing about stuff like: >>>>> W: http://debian.example.org squeeze Release: The Validation date for the archive has expired. (This can indicate an outdated mirror.) <<<<< Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimo3xk5wrojziegmpq1aj1cgimrkxbnlpnxr...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
(better late than never) 2010/6/1 Jacob Sparre Andersen : > David Kalnischkies wrote: >> 2010/5/31 Ludovic Brenta : >>> Question 2: if I add Breaks: to a -dev package, which ones of Conflicts: >>> and Replaces: should I also specify? (currently, both are specified; the new >>> packages replace almost all files of the old packages). >> >> You want only Breaks or Conflicts. Breaks is in general the nicer Conflict >> - in some way they are the negative version of Depends and Pre-Depends: >> Conflicts must be satisfied before the package is unpacked - so both >> packages can't be in unpack (or higher) at the same time, while Breaks only >> says that both can't be in installed at the same time. > > So if there are common files, conflicts is required? You can still add Replaces to replace these files. Conflicts is now that we have Breaks more for cases in which the presence of a package will change the behavior of your package or in situations two packages providing the same functionality in completely different incompatible ways (e.g. sysvinit vs. upstart). Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilmfi7stxn-ua1rlt7njnr06iwlf9s4ompgk...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
(better late than never) 2010/6/3 Ludovic Brenta : > Jacob Sparre Andersen writes: >> David Kalnischkies wrote: >>> With the break you can force the update of old-libs, which >>> could depend in their new version on the new-libs. > > OK, I just tried that (in a local repository). Having gnat break all > the -dev packages in Lenny does not help; the broken packages are marked > as such in aptitude but not removed by default. Worse, gnat is now > marked as broken too (without the Breaks: it is not). Even if I press > '+' on gnat, this still does not cause any broken packages to be > removed; I must mark them all for removal manually with '-'. So we're > back to square one. Mhhh. What does broken mean here? As far as i know aptitude it should come up with a solution in the end in which all packages are in a consistent state (=not half-installed / unconfigured). So it should remove "broken" packages as broken is not a valid state a package can be after a complete $packagemanager run… Just for reference, what does "apt-get dist-upgrade -s" proposes? ( -o Debug::pkgProblemResolver=1 will tell you also why in a more or less cryptical way). It should really work to break old-lib ( << squeeze version) in gnat, to force an upgrade of old-lib to (at least) the "squeeze version", which could depend on your new-lib to get it installed… >>> 2. the old-libs will stay installed in at least of the form of a >>> transitional package in oldlibs as at least apt/lenny has no support >>> for disappear packages so this trick can't be used (not sure about >>> dpkg, aptitude uses apt facility in this regard, so also no support). >> >> This is ugly, but not horrible. > > Does apt/squeeze have support for disappearing packages? Yeap, or at least >= 0.7.26~exp5 has and apt is registered for an abi transition/binnmu series so it will hopefully find its way into unstable/testing some day in the future… (currently blocked) Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim4_sfm0crslumw48coy--z2ifhhlypxn8en...@mail.gmail.com
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
2010/6/6 Ludovic Brenta : > Package: gnat > Architecture: any > Depends: gnat-4.4 (>= 4.4.2-1) > Recommends: ada-reference-manual, gnat-gps > Breaks: libadasockets-dev (<= 1.8.6-2), libasis-dev, libaunit-dev, > libaws-dev, libflorist-dev, libgnademysql-dev, libgnadeodbc-dev, > libgnadepostgresql-dev, libgnadesqlite-dev, > libgnatprj4.3-dev, libgnatvsn4.3-dev, > libgnomeada2-dev, libgtkada2-dev, libtemplates-parser-dev, > libtexttools-dev, libxmlada-dev These breaks need to be versioned - e.g. libasis-dev ( << squeeze) there "squeeze" is the version of the transitional package libasis-dev which depends on the new libasis-newabi-dev just like in a package rename. >>>>> 2. the old-libs will stay installed in at least of the form of a >>>>> transitional package in oldlibs as at least apt/lenny has no >>>>> support for disappear packages so this trick can't be used (not >>>>> sure about dpkg, aptitude uses apt facility in this regard, so also >>>>> no support). >>>> >>>> This is ugly, but not horrible. >>> >>> Does apt/squeeze have support for disappearing packages? >> >> Yeap, or at least >= 0.7.26~exp5 has and apt is registered for an abi >> transition/binnmu series so it will hopefully find its way into >> unstable/testing some day in the future… (currently blocked) > > Could you shed some light or point me to some doc as to how this feature > works? I'd like to know whether it can solve the problem or not. E.g here http://wiki.debian.org/Renaming_a_Package It is not documented very well currently as it can't be used for squeeze and would therefore most likely only confuse maintainers (i guess). Disappear should remove the need in the future for transitional packages (see "apt-cache search dummy transitional"). Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimhxgmdss7xhlsjwnzijy1wjtwlwpf0txqwf...@mail.gmail.com
Re: Improve support for installing 32-bit libraries on 64-bit systems
Hi Michael Tsang (and hi d...@l.d.o) 2010/6/24 Michael Tsang : > I have a recommendation for 32-bit libraries on 64-bit systems: > > Now, some libraries are available on 64-bit systems as lib32* but these are > very few. To improve this situation, I think that we can organise the library > packages as follows: Some problems with this approach are: a) we have multiple 32-bit architectures - i386, arm(el), mips(el), … and even hurd-i386 and kfreebsd-i386 so the naming is ambitious. a1) if you name the packages differently you need to add A LOT of alternatives depending on the architecture to the dependency lines. This not only complicates all these lines but make it also harder to insert new libraries and/or archs as they will slowly propagated in the pool. (Beside that i am not complete sure that an arch depending alternative option is even allowed currently: Depends: lib | lib32 [amd64 sparc64] ) a2) with a different name you avoid the file "conflicts" in at least /usr/share/doc/ - aka changelog, copyright and stuff -- but do they really differ for the same library which is just build for different architectures? So you have a lot of duplicates, right? b) a lot of "duplicated" packages are created: In which way will lib:i386 differ in your (and current) approach from lib32:amd64 expect of the name? c) These lib32, ia32, whatever42 packages tend to be a hell to maintain… (how big is the "source" of ia32-libs currently, 370 MB ? Just a library? *) d) what will happen with the release of a 96bit or 128bit architectures? > This should be implemented as a build template to make all library packages > use this organisation scheme. I think this should be implemented after the > release of Squeeze. If you look closer, MultiArch was at least for squeeze on the goal list. I guess it is pretty unlikely that we will make it, but i think it was more on the list to get a bit of noise and some progress - and some progress is visible. The biggest showstoppers are as far as i know that a) dpkg doesn't support it b) APT doesn't support it c) (not many) packages use it (last time i check ~24) c) is likely caused by a) and b) which in fact decreases the motivation for a) and b) to implement it as nobody use it… *** dependency loop detected *** But don't worry, Debian has found a victi… äh, i mean a volunteer to work on b) [0] - and the good thing is, you can even try and play with it already - you just need an apt/experimental build (, a bit of luck) and the right configuration options. See also README.MultiArch, but (yes, correct, shameless self-advertisement). Best regards, David Kalnischkies [0] http://wiki.debian.org/SummerOfCode2010/APT-MultiArch/DavidKalnischkies which is an accepted proposal and implements it according to the https://wiki.ubuntu.com/MultiarchSpec * yes, that are trick questions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinjwuf_ptvymcwrulur2zjy2ie2knseddluv...@mail.gmail.com
Re: Improve support for installing 32-bit libraries on 64-bit systems
2010/6/26 Luca Bruno : > David Kalnischkies scrisse: >> The biggest showstoppers are as far as i know that >> a) dpkg doesn't support it >> b) APT doesn't support it >> c) (not many) packages use it (last time i check ~24) >> >> c) is likely caused by a) and b) which in fact decreases the >> motivation for a) and b) to implement it as nobody use it… *** >> dependency loop detected *** > > Goswin recently offered some help to improve the situation regarding a) > and c) points, but I've seen no (public) answer from you: > http://lists.debian.org/debian-devel/2010/04/msg00493.html What should i have answered? That i like that he wants to work on a) and c)? I knew that as we exchanged a few mails already as he is also present on deity@ and the associated bugreports, so my only semi-public move as response to this mail was to join the recommend list and proceed in doing "stuff" rather than writing the obvious… especially as i was not a (direct) addressee of the mail and got it a bit later than usual. I can't comment on a) as dpkg is magic (for me at least) and the problem for dpkg is more about reference counting for /usr/share/doc files than dependency solving as far as i understand and should as it is promised be done by someone who know his stuff. It might need to do something similar to what i did in APT with creating pseudo-archdepending packages for arch:all packages to "simplify" dependency solving, for their dependency checking but that depends on their liking, isn't limited by compatibility requirements like it is in APT - and the theory is documented in README.MultiArch and code in case i am hit by a bus, so as long as nobody has (further) questions - nothing to comment… c) is also not my cup of tea so far as i never touched a library by now, starting to tell libary maintainers they should do this and that is at least in my understanding a bit awkward then. (This avoids also a bit pre-seeding everyone with my understanding.) ;) > Given that you say apt in experimental is semi-working, it would be > interesting to join forces and see if something almost test-able can > be provided. Semi working as (obviously) nothing can be really installed as dpkg will jump at you if you try. Semi working also as i focused mostly on the case until now that you have e.g. i386 and amd64 packages available but have only packages from one arch installed (fun-fact: It is i386 for me as i have no amd64 system currently). Requesting to install one or two packages from the other arch will be the most seen use case and this works so far, but only with simple constructed cases as in real world you will be hit by c) - i see that positive as this at least guarantees that APT isn't too relaxed about the dependencies. ;) The ABI changes for it are quite stable and i am especially happy that they are API compatible to the SingleArch-epoch. The APT part left is beside bughunting really the (important) MultiArch "auxiliary" stuff i described in the proposal. > If so, it would also be useful to advertise it a bit more and hoping to > gain some momentum... While many would certainly love it, i don't feel like rushing into a mess. We already saw some tries to implement a semi-multiarch behavior and personally i don't want to see them again. Do it once, clean and for real - and at best not before squeeze freeze or even release: It requires a lot of changes to work correctly in a lot of packages and mindsets and would be currently a waste of time which could better be spent in (rc-)bugs and ongoing or waiting transitions. (At least in the eyes of my mentor and myself. Big bangs after releases generally generate more (positive) noise than near freeze time) And most of the auxiliary stuff has the advantage to be not only "needed" for MultiArch, but fixes a lot of bugs in drive-by mode. Thankfully APT has still so many of them to choose from. ;) Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiklo0ach_m9lqo0ekxxxfnudepm6vdk_cyrc...@mail.gmail.com
Re: Bug#592877: ITP: apt2 -- Advanced Package Tool 2
(cross post to merge the two "independent" threads
http://lists.debian.org/debian-devel/2010/08/msg00338.html
http://lists.debian.org/deity/2010/08/msg00097.html
and to ensure everyone has the same information.
In case you want to discuss the topic feel free to do it at deity@)
We started this discussion already at the announcement mail
for this so called Codename:APT2 so for more context see
http://lists.debian.org/deity/2010/08/msg00057.html
Make sure to read the follow-ups of the two threads above also.
Even more was it discussed on IRC #debian-apt
For the topic itself:
I already got my just deserts so no further comment from me -
beside that i am hereby announcing APT3 which will be written in brainfuck…
(and i am hereby registering APT42 for Michaels or my own use, too)
++
[>+>+++>++>>++>+++<<-]
>>>+.>..<<++.>>>++.>+.+++.<-.>.<.>.+.<.
Best regards,
David "APT{0,1} MultiArch GSoC student" Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktinbsbghxm2n7adjsuanpmtjmbj23vgkjfp-n...@mail.gmail.com
Re: Activating t-p-u by default (was: Re: For those who care about their packages in Debian)
2010/8/26 Paul Wise : > AFAIK to achieve that you need pinning priorities > 500 and < 1000. A pin-value >= 100 is enough in this scenario. > 500 would have maybe even the wrong effect, as repositories which are not from the default-release - if set at all - get 500 per default (expect if the Releasefile says Non-Automatic: yes, then it is pin 1). So setting t-p-u too > 500 would give it always a preference in case no default-release (which gets pin 990) is set. Example: Package: apt Pin: release t-p-u Pin-Priority: 600 apt: Installed: 0.8.0 Candidate: 0.8.1 Version table: 0.9.0 0 500 http://ftp.de.debian.org/debian/ testing/main i386 Packages 0.8.1 0 600 http://ftp.de.debian.org/debian/ t-p-u/main i386 Packages *** 0.8.0 0 100 /var/lib/dpkg/status Note that the candidate is t-p-u apt 0.8.1 and not testing apt 0.9.0 … In case APT::Default-Release (-t option) is set to "testing" the candidate will be 0.9.0 as testing will have a pinning of 990 instead of 500… but in this case 0.8.1 would be never a candidate as long as in testing is still apt 0.8.0 as 990 > 600 and if you manually use 0.8.1 from t-p-u apt will wait with an upgrade until this one or newer is in proper testing… So, to let that actually work a user should not have a default-release… Long story short: If you want to get updates from an archive only if you pushed a version previously from it: 100 => pin > 500. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinoy2_9zczxmktndqe3xve2jx5-gbziybjbc...@mail.gmail.com
Re: Activating t-p-u by default (was: Re: For those who care about their packages in Debian)
2010/8/26 Carsten Hey : > * David Kalnischkies [2010-08-26 17:43 +0200]: >> Long story short: >> If you want to get updates from an archive only if you pushed a version >> previously from it: 100 => pin > 500. > > Wouldn't adding a new field to Release files similar to 'Not-Automatic' > but pin to 101 instead of 1 if this new field is set to yes an option > for apt/Squeeze+1? This has been reported in #186767. Well, yes and no. Technical more or less no problem, but… As far as i understand t-p-u i don't understand why the default should be < 500. If i am adding it (or let a piece of software add it for me) i guess i want these packages on my system: proposed-updates at least suggests for me, that they will be soon in testing anyway, just, that they are tested now before they enter "real" testing in an overlay archive. If i don't want to participate in this testing, i should remove the archive from my sources. If i just want to grab some versions from it, t-p-u doesn't get much testing in general as you must care for this specific package enough to get a new version for it: So new iceweasels are maybe tested a bit, but packages like tzdata will not get any testing through t-p-u… The problem with this is also, which is why i don't think it would be suitable for backports, is that these archives mixing minor only-bugfix releases and new groundbreaking upstream releases… E.g.: I maybe want to get bugfix releases for iceweasel through backports automatically, but what i don't want is an automatic 3.6 -> 4.0 upgrade, but such pinning i need to define by hand anyway. Regarding the bug: What do you do if two non-debian archives provide such a package -- and, do they "fight" against each other now that they can by changing their DefaultPriority? The cleaner way for the user would it be to declare: I don't want to get this package from this archive ever and i care only for these packages from this archive, ignore the rest. You can say that with -1 and Co, but it is a bit harder than needed… So, again in short: I don't see a reason backports shouldn't be pinned to 1 by default and t-p-u by default not pinned at all to get the default 500 pin… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikbzjm8cb9fgg_vtki2h8xjk-7_fpv-e9pmm...@mail.gmail.com
Re: Google Summer of Code 2010 Debian Report
mentor and your community and all this kind of stuff… Reducing the gsoc to "3 months of writing code" you didn't give credit to that pre-gsoc invest of the students as well as you dismiss the hidden target: Encourage a student to use and work on the projects even after gsoc. (which is for me the real and only target: but don't tell anyone) >> As such, you >> should have similar survival rate expectations for a Debian GSoC >> project as for any other Debian project that you or any DD would >> happen to be working on. Perhaps a bit higher, but not much. > > This hits an extremely interesting point. The reference to a "survival rate" > betrays what I think is a major error GSoC administration has made. It seems > the projects selected are in large part new projects, rather than > improvements to existing software. As said, students can provide proposals, the organization can do and even a random stranger can come along and propose something: You only need someone taking it to see it implemented - it doesn't even need to be a gsoc student. If it is interesting enough everyone could take it - but most of the proposals are not interesting. Not that they wouldn't be cool to have, but they are not presented in a "sexy" way. And that is really not the fault of the admins, thats the fault of the project in general or maybe the proposer(s) in specific to be unable to present themself and their proposals in an interesting way. > away from the resources they need, with as only somewhat reliable guide > their mentor, which may not even get 500 USD for the whole mentoring While your mentor is your first contact, you aren't a consult and you shouldn't be handled as such - and you do that if you assume that nobody else in the project needs to care for the student. His primary job is more to get you in touch with others as you don't know the organization you are working in very well (yet) and therefore you don't know always the right contact point for your specific needs. And you don't know all rules right on the first day - simple ones like the code of conduct for debian mailinglists and more complicated ones like debian/rules (sorry, small joke - its easy, too, with debhelper ;) ). > And most importantly, there's Google. Google may do no evil, but they do > good to their bottom line. The SoC brings them publicity, which allows > securing SoC funds for next year. With the current scale of SoC, it's a > mininum that Debian gets 10 slots. An organization of Debian's importance > could get a lot more. Some organizations have over twice as many slots. > Increasing Debian's appeal to Google involves: Google is really not the most important part of gsoc. They pay the bills, yes, but the important part is the student as (s)he does the real work. Especially because (s)he does useful work - its relatively easy to find a job in which I have to do less for more money, but has no value. And if I e.g. want to be treated like a second or third class member I can flip a few burgers and harvest grapes and asparagus instead¹. I don't need to chose debian for that if we would agree that we should handle students as consults… The student need to be convinced to choose debian as organization and at best (s)he should be convinced to stay with debian even after gsoc. Google could provide debian with 20 slots, this doesn't help if only 5 students apply… (that is what I meant with the sex-appeal above…) If debian has 500 students applying, I am pretty sure google will be happy to hand a few more slots to debian… Best regards David Kalnischkies, MultiArch in APT GSoC student 2010 ¹ no offense, depends obviously on the organization, but I grew & grow up in a winemaker family, so I know that different organizations have different treatment styles regarding their workers - and for all gsoc organizations I hope that they didn't use some of these as their blueprint… -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik6ibcsbvdrn=bgaoqqqbwofqtmwdetv7zbr...@mail.gmail.com
Re: Packages/DiffIndex
Hi André, On Wed, Oct 20, 2010 at 09:44, André Berger wrote: > [Sorry if that's the wrong group, please point me to the right one, > if appropriate. I've asked this question on debian-user before but > got no reply there.] mhh, yeah, if debian-users@ can't provide help instantly: ask again - or just wait a tiny little bit longer than 2 days. ;) You could also ask "upstream" - which is in this case the deity@ list. ask.debian.net would be another option to consider next time… anyway: > On my Lenny system, I maintain a small Debian archive. It's updated > with "apt-ftparchive generate". I would like to add a > Packages/DiffIndex file, but can't find out how to accomplish that. apt-ftparchive can't generate the patch files as well as the needed Indexes. This is a feature of dak and/or the other more advanced archivebuilders. Patches are obviously welcomed to change that (as well as someone who takes care of apt-ftparchive as a whole btw) -- in the meantime you can generate them "by hand" maybe inspired by how dak and co does it (for dak you can see it in dak/generate_index_diffs.py i think) or you use one of the "bigger" tools to maintain your archive directly. But, you say that it is "small", so i am tempted to say that pdiffs aren't worthed the hassle. They can be useful if the Packages file is really big and constantly updated, but if it is small… pdiffs have a considerable overhead compared to a complete file download. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=cpyszwcvcvvlfnpszxousveh_satlgew2u...@mail.gmail.com
Re: How to add dependencies that exist in another repository
On Wed, Nov 10, 2010 at 19:57, Henrique de Moraes Holschuh wrote: > On Wed, 10 Nov 2010, Henrique de Moraes Holschuh wrote: >> On Wed, 10 Nov 2010, Bob Proulx wrote: >> > The packages for Debian there add a source.list.d file as you >> > describe. (And it really confused me until I figured out what it had >> >> Which begs the question: why do we even have source.list.d/ suport in >> the first place (or, if it is really useful to other users of apt, why >> is it enabled by default) ? > > Answering my own question: it was done in response to a valid request for an > "include" directive for sources.list. > > See #66325, which asks for, and provides reasonable reasons for a "include" > directive... but people got sources.list.d/ instead, which is a lot more > difficult to keep wraps on. Working with files is easier for a user (or an application working on request for the user) to handle than modifying a single file to include/remove specific sources entries - at least in my eyes. And in comparison: what about e.g. /etc/ssl/certs ? If you want to inject something, you can do it both ways - and after all I can do a lot more in maintainer scripts than adding a sources.list entry, so "mysteriously" added sources.list entries are not a disease (or a misfeature of APT to allow it) but a symptom of the widespread disease of trusting random packages from an unknown sources… Best regards David Kalnischkies (with his APT hat speaking) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik-=gtivtwfqc3dunpv3hrxsd-k-b52hsunr...@mail.gmail.com
Re: How to add dependencies that exist in another repository
On Thu, Nov 11, 2010 at 14:36, Andreas Tille wrote: > to answer the previous question: Yes, I'm using Squeeze. > >> >From man apt_preferences: >> Note that the files in the /etc/apt/preferences.d directory are parsed >> in alphanumeric ascending order and need to obey the following naming >> convention: The files have no or "pref" as filename extension and which >> only contain alphanumeric, hyphen (-), underscore (_) and period (.) >> characters - otherwise they will be silently ignored. > > Well, this defines a *sequence* of these files but what about the > *content*. In /etc/apt/preferences the sequence of paragraphs > does not matter. Just the Pin-Priority value has relevance. So Wrong. The manpage says: > If any specific-form records match an available package version then the > first such record determines the priority of the package version. > Failing that, if any general-form records match an available package version > then the first such record determines the priority of the package version. So its important in which sequence the paragraphs are written (and read). The syntax of the fragment files is (obviously) the same as the one for the main file, so i don't see what an example will help, but here we go: /etc/apt/preferences: Package: * Pin: release experimental Pin-Priority: -1 Package: * Pin: release o=Debian Pin-Priority: 400 /etc/apt/preferences.d/gcc-45.pref: Package: gcc cpp-4.5 g++-4.5 gcc-4.5 Pin: release experimental Pin-Priority: 500 $ apt-cache policy gcc gcc: Installiert: 4:4.4.5-1 Kandidat:4:4.5.1-1exp1 Paket-Pinning: 4:4.5.1-1exp1 Versionstabelle: 4:4.5.1-1exp1 500 -1 http://ftp.de.debian.org/debian/ experimental/main i386 Packages *** 4:4.4.5-1 500 400 http://ftp.de.debian.org/debian/ sid/main i386 Packages 400 http://ftp.de.debian.org/debian/ testing/main i386 Packages 100 /var/lib/dpkg/status 4:4.3.2-2 500 400 http://ftp.de.debian.org/debian/ lenny/main i386 Packages In that example you can also see why the sequence is important - swap the stanzas in the preferences file and all archives which match o=Debian will be pinned to 400 - which includes experimental! But if that doesn't work i guess a bug report is better suited than proceeding in hijacking a thread… Best regards David Kalnischkies P.S.: Yes, i know that the given gcc pinning is not enough, my real stanza is longer - and the preferences file is a pure fiction… -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktingx9yjpuolmt_nv51phs8s+65ey2akh_kg4...@mail.gmail.com
Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 11:32, Yves-Alexis Perez wrote: > On 19/11/2010 08:52, Yves-Alexis Perez wrote: >> Anyone knows why and how to fix that? Would a “breaks” instead of a >> “conflicts” fix it? > > Seems that “Breaks:” doesn't work either: > >> Investigating (0) xfce4-settings [ amd64 ] < none -> 4.6.5-3 > ( xfce ) >> Broken xfce4-settings:amd64 Breaks on xfce4-mcs-plugins [ amd64 ] < 4.4.2-4 >> > ( x11 ) >> Considering xfce4-mcs-plugins:amd64 0 as a solution to >> xfce4-settings:amd64 0 >> Holding Back xfce4-settings:amd64 rather than change >> xfce4-mcs-plugins:amd64 >> Investigating (0) xfce4-session [ amd64 ] < 4.4.2-6 -> 4.6.2-2 > ( xfce ) >> Broken xfce4-session:amd64 Depends on xfce4-settings [ amd64 ] < none -> >> 4.6.5-3 > ( xfce ) >> Considering xfce4-settings:amd64 0 as a solution to xfce4-session:amd64 0 >> Holding Back xfce4-session:amd64 rather than change xfce4-settings:amd64 >> Try to Re-Instate (1) xfce4-session:amd64 >> Done > > I'm not sure why apt doesn't want to remove xfce4-mcs-plugin at all. Any > idea? xfce4-mcs-manager recommends it. As APT has no indication that this package can go away it does the only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise the user will lose functionality… (recommends are defined as installed on all, expect "unusual" systems, so their value is very close to a depends for APT) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktino9o5nfbect-kif1=sj6jgspukvunjp3x4s...@mail.gmail.com
Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 12:59, Yves-Alexis Perez wrote:
> On 19/11/2010 12:29, David Kalnischkies wrote:
>> xfce4-mcs-manager recommends it.
>> As APT has no indication that this package can go away it does the
>> only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise
>> the user will lose functionality…
>> (recommends are defined as installed on all, expect "unusual" systems,
>> so their value is very close to a depends for APT)
>
> Except it's not. System would be perfectly usable with xfce4-mcs-plugin
> and without xfce4-mcs-manager (it wouldn't make much sense, but still).
> Preferring to ignore a Breaks: in order to keep a Recommends: satisfied
> looks to me like the wrong thing to do, though I'm not fluent enough in
> dependencies to be sure.
So, go and start reading. Debian has a lot of dependencies and you have a
lot of possibilities because of that.
You can't use them if you don't know them.
And, more important, you can't blame APT for being stupid if you don't
know what you talk about yourself.
Oh, and in the end, i am not a D{D,M}, so you shouldn't trust me and
what i say about a policy as i don't upload packages to the archive
which needs to comply to that policy…
> By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
> work either, apt will still prefer to hold xfce4-session and keep
> xfce4-mcs-*.
You have way more information than APT - for example:
Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are
now obsolete? No. All which is said is that the new xfce4-session doesn't
work with them (it breaks them). So, for APT its clear that we loose two
packages just to get another one upgraded… that doesn't feel right.
Just imagine dpkg gets a new console interface and therefore isn't
compatible with apt/aptitude anymore - should APT really decide to
remove apt, aptitude and friends just to upgrade dpkg? No. Better wait
for apt, aptitude and friends to be upgraded to work again with dpkg
and retreat from upgrading dpkg now (in that case the breaks would be
versioned, but still).
We have cases in which packages in extra break each other - this
doesn't mean they obsolete each other - it doesn't even say that they
do the same nor even something similar, it just says that they doesn't
work together on the same system (unversioned as the breaks here).
If apt would provide a /usr/bin/apt it could break java for example (and v.v.)
as this provides /usr/bin/apt too - it should be clear that apt and java
have nothing in common expect that they use the same name for
an executable… (yes, thats completely made up, in reality this binary
is already an alternative - but even then it would feel strange to provide
an alternative with apt for javas annotation processing tool…)
Before you ask, no, debian has no way to say: "this package is obsolete -
its fine that it will be removed as other packages take care of its tasks."
The closest thing to that is §7.6.2, but i doubt that this is really such
a drop-in replacement in your case.
(and that doesn't say anything about an upgrade path, too)
So, to solve your problem, you have more or less only one option:
Do not try to clean up behind you, let the package managers do it
(with autoremove or deborphan or whatever). Trying it yourself only
complicates stuff -- and adding Breaks for this kind of stuff is even
against the policy if you want to read it that way: §7.4
> Neither Breaks nor Conflicts should be used unless two packages
> cannot be installed at the same time or installing them both causes
> one of them to be broken or unusable. Having similar functionality or
> performing the same tasks as another package is not sufficient
> reason to declare Breaks or Conflicts with that package.
Or in short: either make empty dummy packages out of them or
just leave them alone.
Best regards
David Kalnischkies
P.S.: The first option will be revisited and properly enhanced at the time
of wheezy (aka "disappearing packages") but let us talk about that later…
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktinb2eg+=+pmhkjrmkcf6t6pwcru-hqd+jfdq...@mail.gmail.com
Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 22:10, Yves-Alexis Perez wrote: > On ven., 2010-11-19 at 19:23 +0100, David Kalnischkies wrote: > >> >> So, go and start reading. Debian has a lot of dependencies and you have a >> lot of possibilities because of that. >> You can't use them if you don't know them. >> And, more important, you can't blame APT for being stupid if you don't >> know what you talk about yourself. > > Well, I thought that Recommends: and Depends: were different things, > which looks to me like a fair assumption. It seems I'm wrong. > > Oh, and I don't really like your tone, and I'm not usually offended by > rudeness. And i am usually not offended by someone blaming APT to be too dumb. APT is all about dependency resolution, so saying you are not to deep into it, but blaming APT to be wrong isn't the best tone either. Draw i would say… >> > By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't >> > work either, apt will still prefer to hold xfce4-session and keep >> > xfce4-mcs-*. >> >> You have way more information than APT - for example: >> Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are >> now obsolete? No. All which is said is that the new xfce4-session doesn't >> work with them (it breaks them). > > No, xfce4-session depends on xfce4-settings. And xfce4-settings > *replaces* xfce4-mcs-*. > >> So, for APT its clear that we loose two >> packages just to get another one upgraded… that doesn't feel right. > > Even with the Replaces: bit? Great, just that Replaces: only says that some files will be replaced, not the complete package… (so its mostly only used by dpkg). APT currently Replaces: manpages-pl as it ships its own manpage translation now. Should APT assume now while upgrading itself that it is a complete replacement for manpages-pl ? My example with apt and java is similar: They will declare Replaces and Breaks as they conflict on filename usage and installing the one breaks the other… java is still no valid upgrade path for apt nor vise versa. >> So, to solve your problem, you have more or less only one option: >> Do not try to clean up behind you, let the package managers do it >> (with autoremove or deborphan or whatever). Trying it yourself only >> complicates stuff -- and adding Breaks for this kind of stuff is even >> against the policy if you want to read it that way: §7.4 > > Except that in my case, I'm more in the $7.6. I'm not adding > Conflicts/Replaces just because I'd like to force people to get rid of > xfce4-mcs-*, it's just that it xfce4-settings needs it. They both ship > common files (along with xfce4-mcs-plugins) They ship common files => Replaces Or is xfce4-mcs-plugins broken now that you replaces some of its files? (or better as footnote 46 suggests: Does it hurt if the files are gone?) Then it really also Breaks:, but you also give the indication that something in xfce4-mcs-plugins is left which can be broken and therefore functionality is lost by removing it… (or allowing the other package to replace files of it in the first place). So you might want to provide a new xfce4-mcs-plugins without these files (by depending on them) which still provides this functionality (or nothing as a dummy package). > and xfce4-settings replaces > the functionality provided by xfce4-mcs-manager. dummy xfce4-mcs-manager depending on xfce4-settings if it is a package rename. If its not, but they do not conflict just leave xfce4-mcs-manager alone. If they conflict as they use the same files, its the same as with the other package… >> Or in short: either make empty dummy packages out of them or >> just leave them alone. > > Which would then need to Depends on xfce4-settings in order to provide > the same set of functionality, adding complexity to the dependencies. In general positive dependencies are easier to satisfy than negative as it is easier to install another package than to remove an installed. If we install a new package we have a relatively low probability that a negative dependency will effect it later. If we remove a package we can be nearly sure that another package depends on it and is now broken. (why would it be installed otherwise?) Also, a user normally doesn't complain too much if new functionality is added, but heavily if some functionality is gone without good reason… And the "good reason" is why APT doesn't remove the package on the breaks - the 'Considering' line in the output shows the scores the packages have. 0 vs 0 isn't a strong thing. If more packages would depend on one of the packages the decision will follow the highest scoring package. To go back to the apt and java example:
Re: [vu...@gnome.org: Cross-distro meeting about application installer]
(re-adding debian-project@ to the loop so both lists have the attendees info) On Fri, Jan 7, 2011 at 10:33, Stefano Zacchiroli wrote: > On Thu, Dec 30, 2010 at 11:58:05AM +0100, Stefano Zacchiroli wrote: >> We're organizing a cross-distro meeting in January to discuss the >> "application installer" topic. It's a hot topic in many distros at the >> moment, and we believe it's an area where we can collaborate a lot. […] >> All the information about the meeting is at >> http://distributions.freedesktop.org/wiki/Meetings/AppInstaller2011 > > Status update on Debian presence there: Enrico Zini has kindly > volunteered to attend as a Debian representative. I'd like to took this Another short update: I volunteered last-minute as a second debian attendee to get the 'platform' APT into the loop, too. Together with our friends from ubuntu we should have a broad coverage and voice for debian in the meeting and a lot to discuss but feel free to provide (additional) topics and opinions for us to bring along to ensure they will be all covered. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=l-obcc75dtyzc3opx6ln_rmt=kx2bbjeg6...@mail.gmail.com
Re: Results of the App Installer Meeting
On Thu, Jan 27, 2011 at 10:26, Andreas Tille wrote: > What I'm missing in the summary and what was probably not discussed is > another user oriented service: ddtp.debian.net. Translating > descriptions of packages^Wapplications is IMHO quite important to do the > last final step to complete world domination. As I know from some > discussion on debian-i18n list[1] DDTSS is severely broken and needs > definitely some love. Some effort to put it under DSA control is > somehow stalled and the technique behind needs some more love by a > gifted and dedicated programmer. Please do not forget: Those users who > say "I want to draw vector graphics." will say it in their mother tongue > and we geeks to frequently forget that this is not necessarily English. > The availability of translated descriptions is IMHO crucial for the > success of the App-Intaller attempt. The DDTP project is quite there > where we need to go but it needs more love. If I remember correctly, DDTP got a short mention and the result was: "Wow, debian really has translations for package descriptions?!?" Other distributions seem to have only failed (=very outdated) tries if any. AppStream focuses on translations of the name, keywords and (short) summary managed by upstream. We talked shortly about longer descriptions (possibly with markdown) but this would easily blow up the currently rather small app-data.xml similar to how the long descriptions are quiet a big part of our Packages files currently - beside the problem: Who will write these descriptions: Upstream is not necessarily the best author… So translated long descriptions are currently out of the (shared) scope, as we simple can't discuss everything in two and a half days, but to add another quote: "It's xml, so we can add anything we like/need later". I guess the DDTP project will be part of follow-up discussions as it is similar to debtags and screenshots - its more or less the only working solution - and you are right: all of them are badly needed. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimhtwxmks7e9ogxvdn2tvfzuprjw90+emy14...@mail.gmail.com
Re: Results of the App Installer Meeting
On Thu, Jan 27, 2011 at 13:45, Andreas Tille wrote: > On Thu, Jan 27, 2011 at 12:55:36PM +0100, David Kalnischkies wrote: >> If I remember correctly, DDTP got a short mention and the result was: >> "Wow, debian really has translations for package descriptions?!?" >> Other distributions seem to have only failed (=very outdated) tries if any. > > IMHO this does show two things: > 1. Debian is cool (people here know this). ;-) > 2. Debian fails to communicate this coolness. :-( Unfortunately yes, debtags got a similar reaction and screenshots wasn't the best known thing either, but what this really shows is that we all fail big-time in communication across distros as I for example personally didn't know a single bit about zypper and the underlying sat-solver or to be fair just a bit more than nothing about the rpm world in general. Debian has a relatively good communication with derivates (thanks front-desk) but between deb and rpm world¹ is a pretty big gulf and on each side we (re)invent the wheel as its hard enough to communicate about your cool new $something in your own world, the "aliens" are even harder to app-roach… ¹ don't even thing of 'world of gentoo' or arch or one of the others now… I am thinking of the AppStream project therefore as a big experiment to work together and I have the strong hope that we can find more places where we can work on together instead of against each other. >> AppStream focuses on translations of the name, keywords and (short) >> summary managed by upstream. We talked shortly about longer descriptions >> (possibly with markdown) but this would easily blow up the currently >> rather small app-data.xml similar to how the long descriptions are quiet >> a big part of our Packages files currently - beside the problem: Who will >> write these descriptions: Upstream is not necessarily the best author… > > The question is: What is a "short" summary. From my packaging Approximation: It is our first line of the long description - at least that is how it is called in rpm world as they have a difference between summary and (long) description. There are btw many ambitions resulting from the gulf as we developed different names for essential the same thing (sections, recommends)… > For the content itself: I agree that upstream is not necessarily the > best author but I assume that maintainers in other dists are doing it > quite similar to waht we do in Debian: Revise a text from upstream or > try to invent one. So the descriptions are there - we just need to > define what a "good" (short) description is (there are bad examples > as well[2]) Thats another usecase of package name matching: "look at how debian describes the 'same' package compared to fedora." Sharing is maybe difficult as some descriptions mention alternatives and/or comparisons to other packages in the archive which is at least inconvenient if the mentioned program isn't packaged for $your-distro. Another thing is the rationality for suggesting an other package. E.g.: To play this foo game on lan with your friends you need to install the foo-lanserver on debian while mandriva ships both bundled… Best regards David Kalnischkies P.S.: A LOT of mails regarding descriptions were send only to the distributi...@l.fd.o list, so we might proceed in talking there. (beware: not subscribers are moderated which is kind of awkward, but heh, I don't make the rules…) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=tnLi7W2m4J7KMPJ5yGPmkhqZ8c2m6Cz2B=l...@mail.gmail.com
Re: does aptitude really need to lock the status database when downloading?
On Fri, Feb 4, 2011 at 01:10, Stanislav Maslovski wrote: > For example, I am running an update on a slow connection and want to > uninstall or install with dpkg a few packages while the others are > being downloaded. Should not this be possible? I understand that there > can be a situation that a dependency could be affected by such an > action, but is not it easy to check for this right before unpacking? As always, the (small) APT team is happy to apply well crafted patches. (and i am sure that is true for aptitude as well) The usecase is so small that until now nobody cared to jump through the holes to ensure that the calculation done before the download is still valid after the download and if not recalculate it. So feel free to tackle it. :) Remember that a recalculation will require to check that nothing is changed in regards to the dependency tree: If we would need to use another path we also install/remove other packages so we need to re-ask if the solution is okay, downloading again, recalculating, … Which breaks the user-interface as nobody (no user and no program) expects a second (and third and so on) question round. But beside that: Yes, it is easy. Workarounds were already presented, so i just want to add that you can also disable locking completely with Debug::NoLocking in apt-get (i guess aptitude accepts it also, but i haven't test it) if you are feeling *extremely* lucky… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinA=rrdoyexmwnukeomxdmw+7jor7wb96c1p...@mail.gmail.com
Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?
On Sun, Mar 6, 2011 at 20:55, Steve Langasek wrote: >> What apt, aptitude do: > >> I don't know. Do they allow an already satisfied Pre-Depends to >> complicate the upgrade path? IIRC dpkg, as an essential package, >> always gets upgraded first anyway, but I am not so familiar with this >> code. To get that straight: It could complicate the installation: Without the Pre-Depends on dpkg it can be in any state, if you depend on it it needs to be fully configured. This is a huge difference every time you want to upgrade package A and dpkg at the same time. Without the Pre-Depends an unpack/configure order problem doesn't exist as they have no connection. Add the Pre-Depends and you have to make sure to not unpack dpkg before configuring A - or the other way around. Will be fun in case of dependency loops. Beside that it is easy to generate "interesting" trees with it like #610991. That said, as dpkg is essential it gets a preferred handling anyway in APT (and friends) and will be unpacked/configured before non-essentials, so in this specific case its more or less a no-op (in squeeze -> wheezy upgrade), but that shouldn't give a bye in general… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimX9_8=javOO0Y5GU0Ytquj5k-S1dUYV_JT=0...@mail.gmail.com
Re: Mirror problems?
On Sun, Mar 13, 2011 at 13:32, Svante Signell wrote: > when apt-updating from ftp.se.debian.org i get the following Hash Sum > mismatch failures: > (it does not happen when using ftp.us.debian.org in sources.list) APT since version 0.8.11 uses the clearsigned InRelease files instead of Release and its detached Release.gpg if possible. The file was announced by the ftpmasters on Nov 15, 2009 - I really thought it would be save to use it more than a year later… "Much to learn, you still have." says my master now and laughs. Unfortunately many mirrors doesn't use the newest version of ftpsync [0] and therefore their two stage update of the mirror is flawed: The InRelease file is updated already in the first stage while all the other indexes are updated in the second stage. As the first stage can have an enormous size [1] there can be quiet a bit of time until the mirror sync is finished in which the hashsums doesn't match (new [In]Release file hashsum record vs. old Packages file). So all in all the problem is temporary. You just have to wait for the mirror update to be finished or simple switch to a not-yet/finished updating mirror if you are really impatient - as long as the mirror hasn't switch to the usage of the newest ftpsync tool of course… btw: The documentation on [0] doesn't include the InRelease file yet. Any pointers where to "complain" about that? d-mirror, d-www, d-…? Best regards The hashsum mismatcher previously (not) known as David Kalnischkies [0] http://www.debian.org/mirror/ftpmirror#how [1] http://ftp-master.debian.org/size-quarter.png -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=Wp8ivrNbu=era7a-rji8ph5gnwtdjzphk9...@mail.gmail.com
Re: holes in secure apt
On Mon, Jun 16, 2014 at 12:04:51PM +0200, Thorsten Glaser wrote: > On Thu, 12 Jun 2014, David Kalnischkies wrote: > > For your attack to be (always) successful, you need a full-sources > > mirror on which you modify all tarballs, so that you can build a valid > > Sources file. You can't just build your attack tarball on demand as the > > Erm, no? You can just cache a working Sources file and exchange > the paragraph you are interested in. That’s something that would > be easy in a CGI written in shell, *and* perform well. Trivial. The "always" refers to the small problem that a MITM isn't in control of what source package is acquired by the user later on. Modifying the Source file is of course trivial, the hard part is making the modification count given that at the time the request for the Sources file is made you have no idea what (if any) source package the user will request in 10 seconds/days following this 'apt-get update' (or equivalent) – if the user isn't on to you given that you have thrown away the signatures for binary packages, too, so that he can't even get his build-dependencies without saying yes to a (default: no) warning. From a theoretical standpoint, this is of course all negligible, but in practice it's so annoying/fragile that way better alternatives exist. (Me messing up InRelease parsing [twice] for example with ironically far less coverage - its all about catchy titles I guess) Best regards David Kalnischkies signature.asc Description: Digital signature
Re: improving downloader packages (was: Re: holes in secure apt)
(so not going to comment on the first part of the thread, beside maybe: Its really sad that it is even suggested that DDs would need a technical solution for the inherently social problem of a co-worker dying…) On Wed, Jun 18, 2014 at 04:21:36AM +0200, Christoph Anton Mitterer wrote: > On Mon, 2014-06-16 at 20:14 +0200, Jakub Wilk wrote: > > [0] And his skepticism was reinforced by (independent) discovery of this > > bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738 > *sigh* and this is still open? 8-O Before someone is rushing to work on that (sorry, I was dreaming)… we actually have a rework for hashsum handling in libapt in our debian/experimental branch which as a minor sideeffect also solves this one. Required quiet some amount of work, multiple api breaks still and uhm… testing… but that is overrated. Someone checking this out would still be welcomed… > I mean MD5 is _really_ broken now... actually I think any secure APT If you happen to have a same-size preimage attack on MD5 I would be interested to hear about it. (Its an interesting lesson in api design though. Having MD5 hardcoded in the Files: field was a bad idea in hindsight. Makes you wonder what horrible situation we were in before a time traveler made it less bad with this design…) > hash some type to be present (i.e. a secure one like SHA3, or SHA512) One of the advantages of the previously mentioned rework is that it would be quiet easy to add new hash implementations - provided we would have an implementation available of course. Best regards David Kalnischkies signature.asc Description: Digital signature
Re: Bug#752589: scowl: Please mark packages as Multi-Arch: foreign
On Tue, Jun 24, 2014 at 06:09:38PM -0700, Don Armstrong wrote: > On Tue, 24 Jun 2014, Frédéric Brière wrote: > > Marking all packages providing wordlist as "Multi-Arch: foreign" would > > allow them to satisfy dependencies from packages of foreign > > architectures. […] > 2) This particular issue in scowl itself would be trivially fixed by > #666772, which has a patch, and has been open for two years with that > patch... > > While I don't see a problem with adding this particular fix to scowl (it > really is Multi-Arch: foreign), we should just fix this archive-wide > once and for all. Note that this apt bug refers to cross-building only, not the general case of (any) dependency on an arch:all package as - as the bug says itself - the general case is potentially dangerous while cross-building is a "new" feature so we could 'break' it left and right. Additional, this is a first-level only change, in other words: Only the arch:all packages the package you want to cross-build are effected by this magic M-A:foreign addition. Anything brought in as a dependency of a dependency is still not magically foreign. There were a bunch of other magic ideas like arch:all packages without any dependencies and so forth, but it usually boils down to a rather simple counter: multi-arch is a relatively complicated beast, do we want to make it even more complex to understand? There are certainly cases in which "magic" would have made sense anyhow, but I am not sure it is a good idea to change it now after 1½ releases supporting it differently – and more importantly for me personally: APT isn't going to support any of this before dpkg does. Once bitten, twice shy… Best regards David Kalnischkies signature.asc Description: Digital signature
Re: Let's shrink Packages.xz
On Mon, Jul 14, 2014 at 12:26:30PM -0500, Jeff Epler wrote: > actually used by current versions of apt. (ideally you'd just go sha256, > but iirc it's the md5sum that is used in practice, even today. but > please find that thread, don't trust my summary) - apt-get --print-uris defaults to MD5 by default as there at least were clients expecting exactly that. jigdo given in the bugreport leading to this default for the time being (#576420). If that is still the case, who knows? In the last iteration the thread "mysteriously" died after I mentioned that we need someone who checks… If you don't like the default: -o Acquire::ForceHash= Still up for takers of course, but I am not holding my breath… - pdiffs index is a SHA1-only fileformat at the moment - Description-md5 is not security related, it just needed for mapping, so using something "stronger" would be non-sense. Something "weaker" would equally work, but that might be a way to ugly transition. - apt-get source uses MD5 at the moment in all released versions, I guess other clients might as well as the fieldname is super handy… (and for us it is also an abi-breaking change) - "the rest" uses the first hash it can find out of SHA512, 256, 1 and MD5 (checking in the order given here, not the order presented in the file). Check for yourself if you really care at which point which one was added… –– modulo all the bugs included of course. The later two change in the yet-to-be finished version currently residing in experimental in so far as that 'source' stops relying on the "Files" field alone and that certain cases in the code will do an all-known hashes comparison instead of best-only (it's difficult to explain which ones these are without expecting a good understanding of how files are acquired by apt, so I go with a "each time we can do it for free" which is surprisingly often 'thanks' to our architecture). Best regards David Kalnischkies signature.asc Description: Digital signature
Re: Let's shrink Packages.xz
On Mon, Jul 14, 2014 at 06:25:47PM +0200, Jakub Wilk wrote: > Description-md5 794.3 KiB 11.9% Needed to provide a mapping as versions change a lot more often than descriptions do; also, historically, Translation-* were outside of the control of ftpmasters (at least, that is what history digging told me). It is also relatively new in the Packages file, which leads me to: With a slight change in semantic we could drop the field from the Packages file again anyhow: At the moment it is the MD5sum of the long description. If it isn't present the clients are expected to calculate it for themselves (well, this was required to work with Translation-* before we moved long descriptions to Translation-en, so very new clients might not know about that). So if we change this to MD5sum of whatever is in the description field (short or long), we could drop it from the Packages file and clients will again calculate this themselves to look stuff up with it in the Translation files (where this field came from). I haven't tested, but that should work without any change in apt (okay, apt-ftparchive needs to be patched), so first stop for someone wanting to drive this is probably dak - takers? Other servers and maybe clients need to be adapted, but that could be done rather uncoordinated as there is usually just one server creating both Packages and Translation-* files, so it will have the same semantic interpretation and clients either take what they get or already implicitely have the "whatever is in the field" semantic. (sidenote: see my other mail for the non-existent security implications of using md5 here if you care) > Description 463.4 KiB7.0% ftpmaster's actually wanted to drop that in their final implementation of the long description splitout. We got the short description back as it wasn't part of the initial plan and clients didn't liked that (= apt-cache search would segfault for example), beside that I prefer to have at least a short description around in any case. I think if we drop one of them, it should be the -md5 field as it isn't as compressible as human-readable text… (not to mention quite useless for a human). > SHA256 1463.8 KiB 22.0% > SHA1938.9 KiB 14.1% > MD5sum 752.4 KiB 11.3% I *guess* the most painless drop would be SHA1. Entirely dropping it from the archive means changing the pdiff infrastructure though. Someone ought to check that claim… Dropping MD5 will break some scripts parsing apt output. I personally hate breaking users, so any takers to check/fix that at least Debian tools do not break? Entirely dropping would be easy after this is done (modulo Description-md5 of course, but see there). Adding/Changing to SHA512 in the indexes is probably close to useless, in the Release file the benefit is probably not worthwhile, but it is here if need would arise. I have some hope that with apt/experimental we will be able to add new hashsums with less pain (aka: no abibreak), too, but that just as a sidenote. > [other fields - present hopefully only for comparison proposes] For the rest it is hopefully clear why we can't drop them, even though I kinda like the idea of dropping dependencies… would make installing stuff so much simpler… ;) > Format changes ala base-whatever, \0, … Changing the format is _*EXTREMELY*_ painful. It is also nice to have a textfile you can work with easily… If you want to improve, this improvement should be factored into a compression algorithm so that not every parser in the universe needs to be rewritten… (one of apts testcases uses 'rev' as a "compression" algorithm. You just need to set some options, advertise the availability in the Release file and you are good to go…) Best regards David Kalnischkies signature.asc Description: Digital signature
Re: Solutions for the Apache upgrade hell
On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote: > On 2014-07-14 08:53:22 +, Thorsten Glaser wrote: > > But I normally use "apt-get --purge dist-upgrade" both to upgrade > > across distros and to stay within one distro (or sid), because > > otherwise I get issues: > > > > * Running upgrade before dist-upgrade sometimes doesn't get the > > dependencies right Revolutionary idea: Report a bug, so that it can be worked out as this is how thousands of users who are capable of reading release notes will upgrade and you don't want them to run into the same problems you ran into, do you? Bonuspoints if you can fix it on way or the other, too. > > * Running dist-upgrade without --purge will keep packages in 'rc' > > state around, which a later APT call will not even recognise; > > you need to manually "dpkg --purge pkg1 pkg2 ..." to get rid > > of them Looks like your upgrade process isn't working as you expect, as you are still stuck with oldoldstable… > I do that too. I haven't seen any official documentation saying that > this is a bad thing to do. aptitude actively warns against it as highlighted in this thread. Official documentation also doesn't say that running 'rm -rf --no-preserve-root /' is a bad thing, but you seem to not run it anyway. In fact, official documentation says exactly how you should perform an upgrade, so it says you at least what is a good thing and you can predict from that that other ways may be less good. > Purging packages in 'rc' state later is not really an option, as I > sometimes want to keep the config files of some particular packages > that have been removed... unless APT can differentiate packages that > have manually been removed and those that have automatically been > removed during a dist-upgrade. I don't understand. apt isn't going on a configuration file killing spree if you don't tell it to do that (and I am not sure how I would tell it to do that even if I wanted it…), but well, no, there is no difference between a package being removed with 'remove' and a package being removed thanks to dependencies (like Conflicts) as this is rather arbitrary difference. Installing a different MTA is probably as much a sentient decision as removing an MTA - and you have agreed to all these actions, so they have your official blessing… apt-get btw doesn't do an automatic remove in dist-upgrade by default, so none of the removes you see are in fact any more "automatic" than the installation of new packages - it is simply needed and part of the job description of a package manager. We have a "apt-get autoremove" for removing packages apt things might not be needed anymore. aptitude does run it by default. Best regards David Kalnischkies signature.asc Description: Digital signature
Re: Let's shrink Packages.xz
On Wed, Jul 16, 2014 at 02:23:34PM +0200, David Kalnischkies wrote: > With a slight change in semantic we could drop the field from the > Packages file again anyhow: At the moment it is the MD5sum of the long > description. If it isn't present the clients are expected to calculate > it for themselves (well, this was required to work with Translation-* > before we moved long descriptions to Translation-en, so very new clients > might not know about that). So if we change this to MD5sum of whatever > is in the description field (short or long), we could drop it from the > Packages file and clients will again calculate this themselves to look > stuff up with it in the Translation files (where this field came from). FTR: This has an obvious sideeffect though: If (lets say) foo/sid has feature x and advertises it in the long description (but short didn't change), while foo/stable didn't have it, it is undefined which description will be shown, it could be any – but it will be only one, the other is 'discarded' as duplicate. Never happens with stable/single archives of course which I was thinking of, but in sid you would see it relatively often. Multiply this with 'outdated' translations still being shown as current. (Did I mention that I dislike feature lists in descriptions as they are always out of date even without that?) You could mix and match it of course, like dropping it for stable as long descriptions aren't going to change there, so that short would be identifier enough, but well… Best regards David Kalnischkies P.S.: version number doesn't work here nicely, as experimental/security do not have translated descriptions, but can piggyback on them this way. Which is the historical reason for this alltogether, as they were first not in the archive and then just file imports (which they still might or might not be, I have no idea – and my last speculation in a train ended in the previous mail - I blame the broken air condition…) signature.asc Description: Digital signature
Re: Bug#756022: ITP: apt-transport-s3 -- APT transport for privately held AWS S3 repositories
On Fri, Jul 25, 2014 at 03:00:17PM +0100, Marcin Kulisz (kuLa) wrote: > * Package name: apt-transport-s3 Note that this is only 'needed' for private S3, apt came to terms with public S3 desperate its problems (like pipelining and decoding of '+') – which this copy doesn't support, but see next section: > Version : 20120426090326git > Upstream Author : Kyle Shank > * URL : https://github.com/kyleshank/apt-s3 > * License : GPLv3 That is surprising to see. It seems to be a slightly modified 6 years old copy of apt's http method (with all its bugs of course) which just got 2 years ago GPLv3(+) headers. APT itself (and the copied code, too) is GPL2+, which this copy avoids mentioning as it doesn't tell you anything about being a copy (looking at some of the forks and how they do the same to https, oh dear…) while the copyright is claimed by the upstream author alone. Slightly modified as the modification in s3.h is the addition of the license header, while s3.cc goes the extra-mile of including openssl (remember, I said GPL2+ – nothing about an OpenSSL exception) and curl (no idea why, as it isn't used) to get SHA1 and Base64 encoding (which is both already available in libapt anyway) to set a "Date:" and an "Authorization: AWS" header for AWS while removing our "Authorization: Basic" support. Oh, and it does change the user-agent from "Debian APT" to "Ubuntu APT"… (and yes, I diff'ed that against an apt checkout from that time as the history of upstream is non-existent). I have the strong feeling that this could just as well be patched into apt directly. Some of the forks (really, 77 forks? for this? apt has a serious marketing problem…) suggest that a bunch of stuff could be added, which I guess are not that okayish for apt directly, but I would encourage you in any case to contact us at de...@lists.debian.org so we can work out how to avoid a massive code-copy as this is (as shown here) prune to get out of date and accumulate unfixed (security) bugs fast. > deb s3://AWS_ACCESS_ID:[AWS_SECRET_KEY]@s3.amazonaws.com/BUCKETNAME wheezy > main btw: You don't need to write your credentials in a sources.list anymore (which should be world-readable) if your apt is recent enough (and with recent I mean at least oldstable). You can populate a netrc-like file at /etc/apt/auth.conf with them (create it if you must and set for it the permissions to your liking!). Best regards David Kalnischkies signature.asc Description: Digital signature
Re: apt-get install sysvinit-core removes gnome?
On Thu, Oct 16, 2014 at 01:20:54PM +0200, Matthias Urlichs wrote: > Florian Lohoff: > > is it intentional that gnome is removed when systemd is replaced by > > sysvinit-core? > > Please always retry this kind of thing with aptitude, and try to let it > choose alternate resolutions to the dependency chains. > > Apitude, too, *really* likes to choose 500 deletions rather than upgrading > even a single package to a version with slightly-lower priority (as defined > in /etc/apt/pref*), but at least you can tell it to try harder. :-/ I shouldn't, I really shouldn't, but well, I bite… This isn't trying harder, it is trying increasingly incorrect solutions to the problem because aptitude assumes the users is not able to express himself correctly. apt-get is treating its user as its god instead, aka: user is always right, even if it makes no sense in apt's simple mind. Selecting one package in an or-group is a grand example of people not understand their tools although the policy is simple and logic: If it isn't impossible to let it win, the first alternative wins. If the package manager would go for any heuristic based on simplicity of installation instead everyone would have lsb-invalid-mta as MTA because that is damn easy to install by any standard. Maintainers are very heavily relying on this property while e.g. building packages. Beside that with every alternative you choose a non-default package for you move further into "here be dragons" land so that should really not be the first suggestion if it can be avoided. A user who on the other hand already knows what he wants has a multitude of options to express his needs/requirements, it is just a matter of how to do it properly… I shouldn't be the one advising against using any aptitude option, because I have no experience with it, but I have enough dependency resolver experience to be able to say that optimising along less removes is very dangerous: Apart from the lsb-invalid-mta example mentioned above, such a setting has no problem with removing essential packages (remember, close to nothing has a positive dependency on it) and aptitude not even has a scary warning for it. I think you should know that before its removing dpkg on your next dist-upgrade (okay, it will not be dpkg, too many positive dependencies for that for now). So act like the chosen configfile name suggests and read the manual, aptitude has one and it documents these kind of things for a reason… If that isn't enough motivation to read it already, let me tell you that the suggested setting isn't even helping in the scenario you described as you optimize for priority first… In terms of the "I don't want package X" problem class its easiest to simply tell the package manager that this is the case. Negative pins and action modifiers on the commandline come to mind. The "don't be an idiot" problem is a bit harder. I actually like apt-get for being so simple minded as it means I can "easily" follow its thought process. The problem with removes is that we tend to bundle a big bunch of different cases into the same group ranging from "these two packages can no longer co-exist; choose wisely as you will loose functionality" all the way down to "this is a transitional package nobody will miss". If you have a clever idea how to solve this, I am all ears… Moo, David Kalnischkies signature.asc Description: Digital signature
Re: apt-get install sysvinit-core removes gnome?
On Sun, Oct 19, 2014 at 09:32:54AM +0200, Matthias Urlichs wrote: > David Kalnischkies: > > > Apitude, too, *really* likes to choose 500 deletions rather than upgrading > > > even a single package to a version with slightly-lower priority (as > > > defined > > > in /etc/apt/pref*), but at least you can tell it to try harder. :-/ > > > > I shouldn't, I really shouldn't, but well, I bite… > > > > This isn't trying harder, it is trying increasingly incorrect solutions > > to the problem because aptitude assumes the users is not able to express > > himself correctly. apt-get is treating its user as its god instead, aka: > > user is always right, even if it makes no sense in apt's simple mind. > > > My main problem is that, whenever I install a "difficult" package, the > first solution I get presented is always to simply not install the package > in question. The next 2^n-1 "solutions" transitively remove everything that > currently conflicts with installing the thing in question. Rejecting the > removal of a few core packages then gets me the correct solution, e.g. > upgrading two packages. I think aptitude is calling this canceling actions. I would bet you can use this config setting to discourage it from doing that, but ultimately its a design choice to allow or forbid them at all. > > Selecting one package in an or-group is a grand example of people not > > understand their tools although the policy is simple and logic: If it > > isn't impossible to let it win, the first alternative wins. If the > > package manager would go for any heuristic based on simplicity of > > installation instead everyone would have lsb-invalid-mta as MTA because > > that is damn easy to install by any standard. Maintainers are very > > heavily relying on this property while e.g. building packages. > > You don't have to drop that part of its logic. Choosing a different package > as a dependency should of course be a "last resort" action (i.e. be heavily > penalized). I'm not talking about changing that. I'm talking about the fact > that aptitude treats upgrading to a slightly-lower-prioritized version of a > package as a *way* worse solution than removing that package (and/or 500 > others). Well, "slightly lower" priority means packages from a different release in general, so that isn't a safe action either. experimental and backports come to mind. Never upgrading to a security fix is another. Also – but that might be a relatively controversial point – users are much better at figuring out which packages they don't want removed compared to e.g. which packages should be held at a lower version, so I can optimize the other values and let the user decide along a property he can easily reason about (I am not suggestion that aptitude or apt-get work that way, but who knows that for sure anyway, right?). > Basically, this boils down to the fact that people shouldn't have to read a > manpage about a complex priority scheme in an equally-complex resolver. > All I want is for aptitude to behave in a sane way by default. > > Its current behavior is not. The usual approach to improving software is to whine about it on mailing lists until its done. While this might work for init systems, it doesn't for most stuff, so the better approach is helping to make it happen. You even made the first step already by realising that the resolver is indeed just as complex as the priority scheme – which can be described in a few sentences. Most people regard them as ancient magic no living human being understands. The irony is that this could very well be a self-fulfilling prophecy as not that many people are left who work on them… (case in point: even with the dirty tricks I pulled to make MultiArch work without too much pain, aptitude with its own solver was still more or less broken by it. I guess I should have done a RoQA while I could… thankfully a small new team materialized out of nowhere later on solving this problem. The history of apt is equally "fun" to look at. We will see when Debian finally run out of luck and does a RoQA ^apt.* I guess…) Anyway, you want to talk about changes to aptitude to someone who is actually into aptitude. aka: ¬me and I doubt you will find such a person in a systemd related thread… Best regards David Kalnischkies signature.asc Description: Digital signature
Re: apt-get install sysvinit-core removes gnome?
On Sun, Oct 19, 2014 at 01:34:13PM +0200, Holger Levsen wrote: > cc:ing the apt maintainers to get their opinion on making this the default... [Disclaimer: I have written the APT part of it. I might be biased.] Hell no – as this isn't the point of the implementation. It is intended to help researchers and developers alike to experiment with resolvers in "normal" situations rather than fabricated snapshots as you can't jump to conclusion about the "greatness" of a resolver based on one single test – and experimentation is basically the opposite of what you would want the default resolver be: The multiple levels of indirection in the design are e.g. great for playing, but horrible from a speed point of view. It would also move a lot of stuff onto every debian system… I guess I don't have to tell you what it means to pull in prio:extra packages from a build-essential prio:important (and for all practical proposes nearly essential:yes) package. It's also not complete yet. The CUDF protocol for example learned very recently what MutliArch is and how to not explode if its encountered, I wouldn't exactly call this path exceptional well tested as a result. [Disclaimer: I have written MultiArch in APT as well, so I flipped between both for quiet a while… not fun, so biased again]. It isn't even clear yet which technique is strictly superior to what we have at the moment as our naturally grown heuristic-solvers do pretty well in real world scenarios. If you don't trust me on that: http://mancoosi.org/~abate/package-managers-comparison-take-2 which talks about http://www.mancoosi.org/measures/packagemanagers/2012/ [Disclaimer: I have written a lengthy comment there which should give you a hint why I come to this conclusion … bias the third] (And yes, while I consider it a bug that apt isn't able to figure this one out without a little help, I don't really consider this case an important realworld scenario. In the end, the times I will change init systems is hopefully far below the GR proposal count for that. Not only because I am lazy, but because it would mean that everyone would have done a pretty crappy job making Debian jessie the best release ever if no init works reliably [totally unbiased on this one] ) Best regards David Kalnischkies signature.asc Description: Digital signature
Re: question about "Conflicts:"
On Mon, Apr 23, 2012 at 09:17, Harald Dunkel wrote: > How can I tell a Debian package to conflict with a real > package "foo", but not with other packages providing "foo"? That is easy: You can't. But it is a strong indication that a packaging bug could be present in foo, foo-provider or your foo-conflicter… so, why you want to do that? Best regards David Kalnischkies P.S.: These kind of questions seem better suited for debian-mentors@l.d.o. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fab57kajduec1hjjwsppwst5zjdyygwxd8wkug-fz1...@mail.gmail.com
Re: question about "Conflicts:"
On Mon, Apr 23, 2012 at 10:35, David Kalnischkies wrote: > On Mon, Apr 23, 2012 at 09:17, Harald Dunkel wrote: >> How can I tell a Debian package to conflict with a real >> package "foo", but not with other packages providing "foo"? > > That is easy: You can't. I meant to include a relative important footnote here: debian-policy §7.5 actually says: "If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict or breakage)." This doesn't reflect current APT-reality through, as it will check the version number of the provider against the attached version number instead. So this might or might not be what you want. I wouldn't depend on that either way… I think dpkg does it as advertised, but i am not sure. Haven't checked other dpkg-frontends. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fAT07xW=hy3uqkuo+vkm9lcm9f9tvlsm0xbdlnsxz4...@mail.gmail.com
Re: APT Signature verification public key
On Tue, Apr 24, 2012 at 12:19, Ritesh Raj Sarraf wrote: > rrs@champaran:/tmp/apt-offline-downloads-31824$ sudo gpgv > --ignore-time-conflict --keyring /etc/apt/trusted.gpg --homedir > /etc/apt/trusted.gpg.d/ /tmp/InRelease.txt > gpgv: Signature made Tuesday 24 April 2012 01:48:25 PM IST using RSA key > ID 473041FA > gpgv: Can't check signature: public key not found I don't think --homedir does work in a way you would need it to work. /etc/apt/trusted.gpg.d/ can include various additional keyrings - the debian-archiv-keyring is one of them. So beside /etc/apt/trusted.gpg you have to pass also all the keyrings in this directory to gpgv. $ run-parts --list /etc/apt/trusted.gpg.d/ --regex '^.*\.gpg$' Will get you a list of files to add. See also apt-key for an example. But maybe you are able to use SigVerify::RunGPGV in apt-pkg/indexcopy.cc or apt's gpgv method (/usr/lib/apt/methods/gpgv) text interface instead of reimplementing them, depending on what you actually need. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fAxSMV5-i+88tVRzC0gDygnH01fWN-bzSG2DZZf¾x...@mail.gmail.com
Bug#671503: general: APT repository format is not documented
On Fri, May 4, 2012 at 6:49 PM, Michal Suchanek wrote: > This, however, does not apply the apt-ftparchive. It is supposed to > create the required files fully automatically. With the provided > documentation I was able to make it do exactly nothing, fully > automatically. For the record: This was reported in a "very friendly" way in #671496. With the correct configuration (which wouldn't be that much harder to write than one for reprepro) it would work as described in manpage and example files, but i agree with Neil that better tools exist - for this usecase at least. Completely ignoring the mail itself and just referring to the title (beside ignoring even the first word in that): "repository format is not documented" is a valid bug - and it should be documented for the benefit of people who write the various tools used to generate repository data. The added benefit would be that we would have a central point where changes/additions can be discussed to avoid problems like we had with the introduction of InRelease or Translation-en which either aren't supported or implemented differently in different tools because nobody knows who the authority is. Currently many (not all) of the discussions with this topic end up on various mailinglists/bugtrackers associated to APT as the lowest common denominator, but this usually means that a lot of people who should be aren't in the loop ending in the previous mentioned problems. I would personal tend toward ftp-master to be the authority with reference implementation being dak, but they have no public mailinglist and dak isn't used by all derivatives… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fak4ibe4kwznqy9toefvvcnfyfo2be-xtxkl3qqmop...@mail.gmail.com
Re: Version for a returning package
On Sun, May 13, 2012 at 7:41 PM, Jonas Smedegaard wrote: > Not yet switched but renewed the old name, advertising new site one only > in words - not technically with 301 redirection (yes, unsupported by APT > but could be put on e.g. front page) The APT http method support redirects since 14. Apr 2009 (aka 0.7.21) which means stable (squeeze) supports it. Everyone who likes that should be thanking Jeff Licquia and Anthony Towns, everyone who doesn't has to set Acquire::http::AllowRedirect to false. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbpmjr3jdyngtjvrhvqvhn9ndtvarommda1vh3xvso...@mail.gmail.com
Re: Version for a returning package
On Mon, May 14, 2012 at 12:36 PM, Jonas Smedegaard wrote: > On 12-05-14 at 09:51am, David Kalnischkies wrote: >> On Sun, May 13, 2012 at 7:41 PM, Jonas Smedegaard wrote: >> > Not yet switched but renewed the old name, advertising new site one >> > only in words - not technically with 301 redirection (yes, >> > unsupported by APT but could be put on e.g. front page) >> >> The APT http method support redirects since 14. Apr 2009 (aka 0.7.21) >> which means stable (squeeze) supports it. >> >> Everyone who likes that should be thanking Jeff Licquia and Anthony >> Towns, everyone who doesn't has to set Acquire::http::AllowRedirect to >> false. > > Cool! > > Sorry that I kept alive obsolete info. > > Might be worth the try to pass on that knowledge to the owner of that > unofficial multimedia repository, in case there was genuine interest in > speeding up the move away from confusing hostname. Might be, that my response was a bit ill-worded: It doesn't help in this case, as a user still has to manually edit his sources.list (i guess at some point the redirect will disappear). APT really only supports the redirect, not something like rewriting the sources.list automatically to satisfy the permanent redirect, simply because editing these files is usually not a good idea in general and editing it just because of a 301 response which could possibly come from a man-in-the-middle is not just not a good idea but an enormous security problem (redirects in general for some definition of problem, hence the AllowRedirect setting). So this response was just to tackle the common myth that redirects are not supported even through services like http.debian.net disprove that every day. Not that you can come around the need for wordy advertisement of this transition with a technical trick. What is usually done is uploading the most-used package (e.g. the keyring) with a debconf message about the transition. I have seen packages doing the flip automatically, which usually ends in a disaster as soon as your users use a mirror or a proxy setup, so i would strongly advice against that (and only mention it so i can advice against it). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbcet2dhywpom91wievvhnmt+pjums+7fj84bo46fs...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 12:46 AM, Adam Borowski wrote: > On Mon, May 14, 2012 at 09:33:34PM +0200, Bálint Réczey wrote: >> 2012/5/14, Marco d'Itri : >> > Do we actually have an official debootstrap package for foreign systems? >> > We could ship a static busybox with it and solve this and other issues. >> > (I know, not all the world is a VAX, etc... But we cannot solve *every* >> > problem.) >> > >> > If the problem is "foreign systems without xz" then we will never be >> > able to use XZ for base. >> How about switching to xz in the standard installer and providing an >> alternate installer with recompressed packages using gzip/bz2? >> >> This would allow us to support most systems and save on bandwidth/mirror >> space. > > Bad idea, I'm afraid. Apt really dislikes seeing two packages with the same > version but a different file size and checksum. You'd have to make sure > that alternate installer never mixes its sources with regular packages. Where "dislikes" means it will upgrade to the first version (defined by sources.list order) with the highest pin (hint: the status file is the last source and pinned to 100), which is the reason for overriding self-build-with-same-version packages: These are usually not in a repository and therefore the last version in the listing. And the fields defining a difference in versions are: Installed-Size, Depends, Pre-Depends, Conflicts, Breaks and Replaces. Differences in all other fields are ignored (as they are not guaranteed to be present - the status file e.g. misses the deb filesize as well as checksums for obvious reasons). So in essence: You have a good chance that gz and xz packages will have the same install size and therefore be treated as equal (assuming that xz packages will be unpacked and repacked as gzip). If packages are rebuild to pack them in gzip the install-size might differ, in that case the version from the first mentioned source will be installed. Beside maybe wasting bandwidth in that case (for the sake of same version for everyone in general) a pretty well defined behavior from my POV. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbr_8a1thg+pre-4cnuweenom9el07m+w+jw__svgc...@mail.gmail.com
Re: Wheezy release: CDs are not big enough any more...
On Tue, May 15, 2012 at 2:56 AM, Russ Allbery wrote: > Charles Plessy writes: >> Le Tue, May 15, 2012 at 01:54:53AM +0200, David Kalnischkies a écrit : > >>> And the fields defining a difference in versions are: >>> Installed-Size, Depends, Pre-Depends, Conflicts, Breaks and Replaces. >>> Differences in all other fields are ignored (as they are not guaranteed to >>> be present - the status file e.g. misses the deb filesize as well as >>> checksums for obvious reasons). > >> Installed-Size is not marked as mandatory or recommended in the Debian >> policy. Do you think this is something to be corrected ? > >> >> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles > > Installed-Size is generated automatically by dpkg-buildpackage, so the > only way that you'd get a package without it is by manually creating a > package, which nearly no one does. So in practice it's always there, > although it might not be a bad idea to make that clear in Policy. It's not a problem per-se if the Installed-Size field isn't there, it will just be ignored - not like a missing Package field APT will complain big time about and is therefore mandatory. Haven't checked but dpkg properly doesn't care at all for this field. An archive creator extracts the size from the control file for the Packages file, so it will usually have the same value (or none), so this shouldn't generate different versions at all, but even if it does the worst which can happen is that APT will schedule a package for upgrade again and again. The only missing/wrong bit of information will be the line in apt-get output informing a user how much space will be used/freed by this operation. It's a bit of a stretch to make a field "recommend" just for this use, so i didn't consider that an issue, but i wouldn't argue about it being added to the recommend set either. The more interesting really pathetic issue is that this section doesn't make non-empty Depends (and co) mandatory (advanced question: would Recommends, Suggests and Enhances be it as well?), but if these fields are missing if they shouldn't you are properly doing something very wrong anyway and deserve some pain… (a commit from 1999 commenting out Recommends and Suggests in this code suggests that both could go away if different tools are used) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fC=dLK6qsFSA2bM-_u6TVBCt8bYio_Qbz1bBbfd...@mail.gmail.com
Re: Bug#481129: Bug#671503: general: APT repository format is not documented
you want to continue to use that script, so please don't keep up the myth that we changed everything and nobody told you why and how and what not. If you are really that unsatisfied with apt, feel free to use something else, we have enough tools to choose from, it not like apt would be the only package manager in existence. It might be the most used one, but that doesn't say anything about documentation or available manpower. > The status was 'documented' by existing repositories which stopped > working. You would complain to the mechanic who fixed the oiltank in your car that you are now no longer able to follow the oil drops back home, right? If we want to follow that thought, the only repository which should give any indication on how APT might work is the one created by the ftpmasters. Actually that is not really true as APT could basically do anything, but if it wants to keep the status 'debian native' package it better should. And ftpmaster could basically do anything, but this would properly make quiet a few people (a bit) angry. Anyway: "Documented" is it absolutely not by any random repository which just happened to sort of work because its maintainer was lucky and thinks that "if it builds without a fatal error, it must be perfect". Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fDCZ4AtpAQGHZW1=5jlw6cjslhd8dz7gog+0a9rk+x...@mail.gmail.com
Re: Bug#481129: Bug#671503: general: APT repository format is not documented
On Sat, May 19, 2012 at 2:00 PM, Julian Andres Klode wrote:
> = Flat Repository Format =
>
> A flat repository does not use the {{{dists}}} hierarchy of directories,
> and instead places meta index and indices directly into the archive root
> (or some part below it) In sources.list syntax, a flat repository is specified
> like this:
>
> {{{
> deb uri directory/
> }}}
I don't think defining sources.list syntax in a client-agnostic document
is a good move. APT has the 'sources.list' manpage for it and other clients
might or might not have different ways to specify repositories.
(beside, that it would be deb-src, too)
> !InRelease, Release, Release.gpg meta-information are supported as well.
> Diffs,
> Translations, and Contents indices are not defined for that repository format.
> Indices may be compressed just like in the standard Debian repository format.
Translations are supported, although with a different name: directory/en
(and co) instead of Translation-en. For Contents i am not sure, but i think
apt-file downloads these, too. (not sure if this should be a reason to include
it in a specification through or just keep it as some legacy cruft around)
Diffs are supported by apt, but it will not be used if not in Release.
(if no Release file is present, diffs will not be tried).
It's the same for the non-flat repository and true for other files as well
- and should be a reasonable thing to allow clients to do.
In that train of thought, I think it would be a good idea to require a
repository to have a Release (or InRelease) file including all files
[in their current state] composing this repository.
They are easy to create and this way a client could stop guessing if
they like to, avoiding possibly a lot of 404's.
Best combined with a strong recommendation on signing them.
Best regards
David Kalnischkies
P.S.: Could we please stop talking to three bugs and two mailinglists?
Especially as [0] suggests it is the wrong list…
[0] http://lists.debian.org/debian-devel/2012/05/msg00222.html
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fbybj8mqxssmdjm3naxq9v62usw3w-3juea-8eng...@mail.gmail.com
Re: amd64 as default architecture
On Sun, May 20, 2012 at 1:10 PM, Sven Joachim wrote: > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote: > >> Slightly OT but I wanted to mention it for its similarity: >> >> One thing that should be tested and then documented prominently as yay >> or nay in the wheezy upgrade notes is wether one can cross-grade from >> i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and >> then migrate to a 64bit userspace. > > Won't work in wheezy, apt does not support crossgradesน. There is no real reason to require apt to do the heavy lifting here. It would be nice, but it is a one-time action, so a specialized tool wouldn't hurt muscle memory too much. Install essentials and apt and you should be good to go to proceed as usual, just with a different architecture… Even most essentials are easy to crossgrade, the only really difficult one is dpkg and it's dependencies as you have to take care of not breaking it while it crossgrades itself. (I think it is unlikely that apt will get support for that soon, if at all, given that it quiet easily becomes a quiet complicated situation in general in a codearea which isn't short on complexity already. And that just for the "once in a blue moon" encounter of a crossgrade?) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fD1OraGQoEWuWe&-1jxtcz+tq0d2x4v7vspfd8ba...@mail.gmail.com
Re: "could not perform immediate configuration"
On Sat, Jun 23, 2012 at 6:23 PM, Andreas Beckmann wrote:
> On 2012-06-23 12:55, Vincent Bernat wrote:
>> I was suggested to turn `roundcube-sqlite` into some kind of
>> transitional package. But it seems difficult for me to choose between
>> `roundcube-mysql` and `roundcube-sqlite`. And it does not explain why
>> APT does not know how to handle this.
>
> This should be working in apt in wheezy (I didn't verify it), but that
> is not available at dist-upgrade time.
I can't reproduce this in either version with our usual testcase creator
(apt/test/integration/create-test-data), but these testcases aren't exactly
what helps here, so it's kind of expected. If you want a definite answer
attaching a real /var/lib/dpkg/status to the bugreport should help.
[In general, as this might come up more often in the next weeks]
It can be feed to APT with the -o dir::state::status=/path/file option.
Simulation might not catch everything and the ordering is done after
the download, so you have to download the packages and display
instead of calling dpkg ( -o Debug::pkgDpkgPm=1 ).
[In apt/wheezy you can skip downloading with
-o Debug::pkgAcqArchive::NoQueue=1 ]
Beware that this still runs configured hooks, so you might as well
just try it in a chroot or have a look at apt/test/integration/framework
how it setups up APT and dpkg -- of course, you can just as well
try to write a testcase, it's not that hard - but I am drifting off.
Semi-Offtopic: Interesting options for resolver debugging are:
-o Debug::pkgProblemResolver=1 # printing evaluated one-on-one fights
-o Debug::pkgDepCache::Marker=1 # Mark{Install,Delete,Keep} calls
-o Debug::pgkDepCache::AutoInstall=1 # dependency resolution
Back at the problem at hand:
I think it is more a problem of the tree below roundcube-*:
php-mdb2-driver-sqlite is dropped from wheezy, too
(which btw has still horde3 and ansel1 as rev-depends in or-groups).
php5-sqlite breaks roundcube-sqlite, so different roundcube-*sql*
packages can't co-exist.
Not sure why exactly that should be a problem, but a transitional
package probably doesn't hurt.
[Haven't looked too deeply into it as neither time nor data plan allows
it though, so I reserve the right to change my mind any minute]
> On the other hand, adding the following transitional package:
[…]
> "Transitional packages are your friend, conflicts are not" D.K.
I would be delighted by the quote, if I wouldn't be a bit embarrassed
that this comes from a mail I am not particular proud of …
Internet, "thou art a heartless bitch" (sometimes).
(or instead of blaming the web, simply don't write mails in a bad mood)
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fAQRKjffGs=EPzcC=2_wa9-mo3mxwyw5wd8zfbmsaf...@mail.gmail.com
Re: Introducing http.debian.net, Debian's mirrors redirector
On Thu, Jun 28, 2012 at 7:55 AM, Raphael Geissert wrote: > APT guys: perhaps someone of you have an idea as to what is happening? > Running apt-get update twice in a row, using http.d.n, and stable, will > result in the Packages file being downloaded both times. Even if unchangeed. Which version should that be? I can't reproduce it with: # debootstrap --variant=minbase squeeze squeeze-minbase http://http.debian.net/debian # chroot squeeze-minbase/ # apt-get update [Hit on Release.gpg, Release, Packages - no download ] # rm -rf /var/lib/apt/lists/ # apt-get update [Gets Release.gpg, Release, Packages - ~8MB fetched ] # apt-get update [Hit on Release.gpg, Release, Packages - no download ] Did the same with a sid chroot, expect changing the sources to squeeze of course and still no dice - sorry. Are you sure the involved servers respond correctly? [Demo page says for my test: 130.83.114.189 | 8365 | EU | DE] (You can see some sub-optimality here if you try it with a pdiff enabled-sources as it should know after hitting Release that the rest of the files can't be changed [or if they are, this means we get a hashsum error anyway] and therefore shouldn't download the indexes for the pdiffs - but this is done also only a single time) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fAhkLqsqDkPsgNT+Fru8oT0+65hqFb4GxChCGMr=mn...@mail.gmail.com
Re: Bug#680226: lib{nss,pam}-ldapd: apt wants to remove them on dist-upgrade in favour of lib{nss,pam}-ldap:i386
On Fri, Jul 6, 2012 at 12:06 AM, Arthur de Jong wrote:
> I guess the conflicts is interpreted to apply to any installed version
> of the package while what should be interpreted as a conflict/replaces
> only of the package of the same architecture.
Correct guess. "Negative dependencies" (Breaks, Conflicts, …) apply
to all architectures. (Any) architecture-specific dependencies are not
allowed in wheezy as APT and dpkg gained support for them only very
very recently, thanks to Thibaut Girka. I am not sure if they are allowed
even then in negatives though (and I doubt APT supports them there
currently).
Long story short:
> I'm not sure what the proper way is to specify that Conflicts and
> Provides should only apply for a same-architecture version of the
> package. If I do this (just trying some things):
There is simple no way.
> Provides: libnss-ldap:${Arch}
Provides on the other hand are architecture specific by default.
They are only non-architecture specific if you mark the package
M-A:foreign - I hope it is obvious why.
> # dpkg -i libnss-ldapd_0.8.10-2_i386.deb
> dpkg: error processing libnss-ldapd_0.8.10-2_i386.deb (--install):
> parsing file '/var/lib/dpkg/tmp.ci/control' near line 9 package
> 'libnss-ldapd':
> 'Conflicts' field, reference to 'libnss-ldap': invalid architecture name
> 'i386': a value different from 'any' is currently not allowed
Which dpkg version is that?
But as said, you can't use architecture specific dependencies in wheezy.
(The message is a bit confusing, :any doesn't make a lot of sense here
provided that it is the same without :any … or worse: any could mean
we are conflicting only with one arch at random, if you have a second
installed you might be lucky - or not - depending on moon phase)
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fa2r+tbsxscau6mnimzfdm4tyggs+zmb__f0r9ez8e...@mail.gmail.com
Re: Recommends for metapackages
On Tue, Jul 10, 2012 at 10:53 PM, Andrei POPESCU wrote: > On Ma, 10 iul 12, 22:38:59, Eugene V. Lyubimkin wrote: >> On 2012-07-10 22:21, Andrei POPESCU wrote: >> >> > but maybe package managers should gain a >> > "Install-New-Recommends" option defaulting to true? > ^ > >> Recommends are installed by default for quite a time already. > > Sure, but not new ones :) Oh really? Then please tell me what this code does: http://anonscm.debian.org/loggerhead/apt/debian-sid/annotate/head:/apt-pkg/depcache.cc#L1103 (and yes, minus refactoring and bugfixing, this code is older than the switch to enable installation of recommends by default for lenny …) Now, you might as well talk about other package managers, but if so, please be specific so that a problem can be fixed rather than talked about every two years in a thread about what should be installed by default or not in a very unspecific "doesn't work at all" way. It is enough if we talk in that style about the package in question, we don't need to extend that style to everything else in the thread … (I wouldn't mind if we would stop talking in that style at all, but I don't use n-m, so in that specific case, I don't care …) Best regards David Kalnischkies, who doesn't know whether to laugh or cry about these kind of threads … -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fdtaydt1ubp08yf0d8l0jusffy1rzyhvmvztfcjeoc...@mail.gmail.com
Re: apt-get fails with "system" message bus problem
On Mon, Sep 3, 2012 at 5:17 PM, Malte Forkel wrote: > $ fakeroot apt-getfrom -s "deb http://ftp.debian.org/debian stable \ > main" download debian-archive-keyring > Failed to open connection to "system" message bus: Did not receive a > reply. Possible causes include: the remote application did not send a > reply, the message bus security policy blocked the reply, the reply > timeout expired, or the network connection was broken. Without the code we will never be sure, but this sounds like a message from a dbus client. It's at least nothing apt-get would print as it is one of the few lower-level tools not talking over dbus so far … SCNR I presume your script runs 'apt-get update' and you have something installed which plugs into one or more of the hooks: APT::Update::Pre-Invoke APT::Update::Post-Invoke-Success APT::Update::Post-Invoke In your case it is probably 'aptdaemon' which wants to be notified about changes to indexes, but in these slots could possibly be a multitude of different stuff which all think they are executed by root … As your 'update' is not one for the system these hooks probably shouldn't be run, so easiest option is to #clear them; see the apt.conf manpage for that. Way better is to not use the configuration present in /etc/apt/ at all. You can achieve this by using a configuration file defined by the environment variable APT_CONFIG and setting the paths to the respective directories to something you have absolute control over. See in the apt sourcecode the file test/integration/framework, specifically the setupenvironment function in it, to have an example of what can be done if you pull the right strings. (aka: With a bit of setup you can even install packages in a temporary directory as user -- wouldn't try it with real packages through: Maintainerscripts probably cry hovak in such a "faked" "chroot" …) I wonder what you script is used for through. Why do you want/need to provide a mirror? What is it that you can't just use e.g. apt-get download debian-archive-keyring/stable (beside that this functionality is not in squeeze of course, but aptitude has a similar command - but I haven't tried) If you can convince me, the functionality might magically appear one day in an APT version … ;) Best regards David Kalnischkies, who has an phone which makes heavy use of dbus, so he really shouldn't make lame jokes about dbus… -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fC53Vne67hv3Mfe8hyyANG=ct9qyr_jsrago18azfb...@mail.gmail.com
Re: Algorithm for selecting between packages providing the same phpapi-20100525, change between squeeze -> wheezy
(funny, talk without end about init systems, but not a single response for a Debian native tool for a few days… and with funny, I meant sad) On Mon, May 20, 2013 at 3:16 PM, Ondřej Surý wrote: > I am just curious about the selection mechanism in apt(itude), > something has changed between squeeze and wheezy. apt and aptitude are not the same program and have very different behavior even through they share a 3 letter prefix and a library in various areas, so don't assume that what I am saying about the resolver in libapt which apt-get is using has anything to do with aptitude which has its own or the various other libapt front-ends which might or might not use the solver, or use it differently. (Ignoring that most of them could use an external solver) > When I was noticed by a user that libapache2-mod-php5filter is > installed by default when phpapi-20100525 (f.e. try installing > php5-mysql in squeeze and wheezy). […] > It seems that apt is ignoring Priority: (php5filter is extra) Actually, its not ignoring the Priority, in fact it sorts by Priority, just that the order changed "recently" (Nov 2011). A certain individual – who I am not going to call out in public to protect him from the lynch-mob – made the mistake of changing the code to sort lowest priority first … (fixed in his branch now & added to the wheezy-maybe list) > The solution would be to pick one default SAPI and do php5-SAPI | > phpapi-20100525, but that would be hard to push into all r-depending > PHP modules. This is indeed the recommend solution if you have a default as nowhere is defined which provider of a priority is chosen. While priority might be an obvious and easy choice for solvers working with a heuristic, I wouldn't be surprised if more deterministic solvers would go for the least 'changes' instead which might not be an optimal "default" choice. Maybe you want to try it with: apt-get install $whatever --solver $solver [where $solver is likely "aspcud" as we haven't that much more so far] Also: build-dependencies, but that is probably not an issue for PHP. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fdjfr7jvnx6b0wgttjpunbhhsmzuw48chmn2kmf-de...@mail.gmail.com
Re: Berkeley DB 6.0 license change to AGPLv3
On Wed, Jul 3, 2013 at 5:34 PM, Bradley M. Kuhn wrote: > On (b), I think the discussion about apt needing to be (effectively) > AGPLv3-or-later to continue using BDB is salient. I, for one, would > like to see such a thing, but I'm a biased party who co-authored AGPLv3 > and believe in its policy goals; I'd like to see more software under > AGPLv3! But, I also see it from the point of view of Debian developers > who might feel this sort of policy change is too drastic a move to the > strongest copyleft available. So, as I see wrong bits a few times in this thread now: a) APT is GPL2+ licensed and will stay that way out of no other choice as I bet its more likely that hell freezes over than that we track down every contributor since 1997 to ask for an agreement for a license change … (yes, we could switch to GPL3+ "for free", but it's not like we would gain anything from it – beside generating problems for GPL2-only dependees on libapt of course) b) src:apt depends on libdb-dev for apt-ftparchive which is shipped in apt-utils. I doubt it is insanely hard to switch to another database if we would need to – the database is used as a cache, so not even strictly needed – but GPL2+ is compatible with AGPL so I don't see why. (Also, you can't interact with apt-ftparchive over the network, so no practical difference) Other parts of APT have no relation to libdb whatsoever. Sidenote: Debian infrastructure (aka dak) isn't depending on apt-ftparchive anymore ["just" "some" derivatives use it nowadays], so the binary is even less important than you might think/remember. Disclaimer: This is not a remark regarding AGPL. I am just trying to correct misunderstandings in regards to APT. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fcfhgmkmx6a4hdvv5ysp_+siyqwfn7gdfk+j3bmbcv...@mail.gmail.com
Re: Algorithm for selecting between packages providing the same phpapi-20100525, change between squeeze -> wheezy
On Tue, Jul 9, 2013 at 2:25 PM, Ondřej Surý wrote: > will this bug get fixed in wheezy? Just asked Michael about it again as we forgot about it for the last one, but as said, you are depending on an implementation detail of libapt, so this isn't going to fix your problem if another solver is used (e.g. aptitude [as it isn't using the relevant code] or an external solver). So just to repeat myself: Policy isn't defining which provider should be chosen, its assumed that the maintainer is expressing a preference or if not that ANY provider can be chosen based on whichever criteria the solver might want. (Still no checked what aptitude uses, but I bet its some sort of 'least disruptive changes' which is obviously better than priority alone, but not at all working in your favor of course) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fBK2XYUEfVTmi1_Q6A0PT3UQ96esZOthjsOPgy=pee...@mail.gmail.com
Re: [Popcon-developers] Encrypted popcon submissions
On Thu, Jul 11, 2013 at 5:15 PM, Daniel Leidert wrote: > Am Donnerstag, den 11.07.2013, 15:33 +0200 schrieb Bill Allombert: > JFTR: The file secring.gpg can be avoided using > --secret-keyring=/dev/null but I don't know how to suppress the creation > of trustdb.gpg. Note that you can't use that for all gpg commands, importing a (public) key is e.g. not possible with this. You have to create an (empty) file in that case as e.g. apt-key is doing it. "Suppressing" trustdb.gpg is even harder as an empty file isn't accepted, so you have to create a temporary directory gpg can store the file in (apt-key doesn't as it eats quiet a bit of time if you have a few keys). And then you have gpg editing keyrings at times ( #687611 ) even if you just --list-keys which you might be able to stop with --no-auto-check-trustdb (I haven't had the time to test that yet; and if it really works, I find the name a bit strange but I have stopped wondering about such things). Ignoring time screws (--ignore-time-conflict) might or might not make sense depending on how much the time is important for the application in general (doesn't apply to popcon I guess, but in case someone else reads the thread). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fCtK_OcAwN8CcBG21CKCoJwcoouU36KhVSn_q=6_lu...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Sun, Jul 14, 2013 at 10:57 AM, John Paul Adrian Glaubitz wrote: > On 07/14/2013 06:45 AM, Thomas Goirand wrote: >> >> These aren't the only viable option and you know it. FYI, OpenRC port to >> Debian is doing well, and it is already able to boot a Debian system >> with current init script unmodified. Remaining to do: >> - support for update-rc.d >> - support for invoke-rc.d >> - finish the init.d script compatibility (not much remaining to do) >> - make it work with an unmodified /etc/inittab >> - add support for X-Start-Before (that might be the hardest part) > > > OpenRC has already been discussed for Debian for over a year, it's still not > fully ported and working, yet you claim the port is doing well. > > Are you seriously expecting anyone to use such a patch work on a productive > machine? At least I am seriously expecting that Debian isn't discarding the outcome of a project it has officially endorsed to be under its umbrella for GSoC without even the slightest bit of consideration. GSoC in Debian was announced a long time ago, enough time to raise any objections against any proposed project. Either this wasn't done or it wasn't done loud enough as the OpenRC project was accepted and is now being worked on by a student, so its too late to voice any concerns now as this is just slapping the student right across the face. Its at least nothing I would do while trying to hook a student to continue working in/on Debian even long after a specific project is done (and GSoC ended). Feel free to evaluate (any project) after it is finished and draw your conclusions from that (for the specific project, GSoC in general, …), but don't complaining about it without even trying. Last I heard, that was exactly systemd fanbase complain: that everyone just complained without even trying it based on hearsay. So, lets try "leading by example", shall we? >> These issues are fixable, and I have a good hope that it will happen >> before the end of the GSoC project. And there's also upstart as a quite >> realistic option too. > > > The difference is, however, systemd is already there […] It is not "already there". That was the whole freaking point of this "survey". There is still enough time for anythings fanbase to bash each other. Just avoid beating new contributors in the process who might not have developed a thick enough skin just yet. Best regards David Kalnischkies, who couldn't care less about init systems^W^W"System and Service Managers" so try to avoid putting him in some fanbase camp please. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fD_jO6u4hZXhvE=wvr9rpoegvoy9q0ekzfx3cjdt...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Sun, Jul 14, 2013 at 2:38 PM, John Paul Adrian Glaubitz wrote: > On 07/14/2013 01:09 PM, David Kalnischkies wrote: >> >> At least I am seriously expecting that Debian isn't discarding the outcome >> of a project it has officially endorsed to be under its umbrella for GSoC >> without even the slightest bit of consideration. > > > I didn't know that someone is working on OpenRC under the umbrella of GSoC. > Don't make any assumptions, please. I am sorry, but I figured that because Thomas was talking about this project with the keyword Debian and GSoC in his mail that this would be known. >> Last I heard, that was exactly systemd fanbase complain: that everyone >> just complained without even trying it based on hearsay. >> So, lets try "leading by example", shall we? > > > There is no systemd fanbase. I am not favoring systemd because I like > Lennart or because I think the name is cool, but because systemd is > objectively the far superior solution developed by experienced developers. > > Debian isn't a toy project, it's supposed to be used on production systems. The benefit of being the "objectively far superior solution" is that you don't need to be scared of competing with inferior solutions, as you will always win in Debian. No name calling, no politics, no popularity contest, just pure clear objective facts everyone can validate by trying it out. If the student delivers a project which can be evaluated for its technical merits, we have won a lot, as this automatically shuts up every "what if we adapted this to our needs" … That path was explored, it didn't prove useful because … kthxbye. A lot better than trying to argue with not objective arguments. I am not going to comment the other parts as I assume it is not meant to be commented – especially as your second to last sentence suggests that we actually have the same goal and just approach it differently. I am suggesting to read about GSoC (and similar) in Debian though. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fBUpjCPef9TzNrYDaH™dtpkpq0brdbpey+5t6vj7...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Sun, Jul 14, 2013 at 3:47 PM, Florian Weimer wrote: > * David Kalnischkies: > >> GSoC in Debian was announced a long time ago, enough time to raise >> any objections against any proposed project. > > Not really, a GSoC project doesn't come with any guarantee, implied or > otherwise, that any deliverable is actually used by the mentoring > organization. That is fine (at least for some definitions of fine. Ideally everything would be picked up – and of course also proposed in a way that it can be picked up – but that is unrealistic). But there is a difference between "not used after its done as the project proofed that it is not able to deliver something more valuable" and "saying midway that whatever the student does, it will be discarded". We have a student who works on that stuff, so the least we can do is check if whatever the outcome will be can be useful for Debian, even if the outcome is that it is not useful for Debian at all – that is at least a technical argument someone can work with and removes a candidate from the pool. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fCuLWPRr2+m+tZ=6xW+V3EE-Ji-qb=6mxkhsobtntf...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Mon, Jul 15, 2013 at 2:56 AM, Ben Hutchings wrote: > On Sun, 2013-07-14 at 13:09 +0200, David Kalnischkies wrote: >> On Sun, Jul 14, 2013 at 10:57 AM, John Paul Adrian Glaubitz >> wrote: >> > On 07/14/2013 06:45 AM, Thomas Goirand wrote: >> >> >> >> These aren't the only viable option and you know it. FYI, OpenRC port to >> >> Debian is doing well, and it is already able to boot a Debian system >> >> with current init script unmodified. Remaining to do: >> >> - support for update-rc.d >> >> - support for invoke-rc.d >> >> - finish the init.d script compatibility (not much remaining to do) >> >> - make it work with an unmodified /etc/inittab >> >> - add support for X-Start-Before (that might be the hardest part) >> > >> > >> > OpenRC has already been discussed for Debian for over a year, it's still >> > not >> > fully ported and working, yet you claim the port is doing well. >> > >> > Are you seriously expecting anyone to use such a patch work on a productive >> > machine? >> >> At least I am seriously expecting that Debian isn't discarding the outcome >> of a project it has officially endorsed to be under its umbrella for GSoC >> without even the slightest bit of consideration. > [...] > > GSoC Debian projects are not 'officially endorsed by Debian'. So far as > I understand it, they are supported by at least one DD (proposer and > mentor, may be the same person) and accepted by the GSoC coordinator; > that's all. Having Delegates working on it makes it sound pretty official, but I agree that I have worded it a bit (too) strong in an ill attempt to match the style of the sentence above. Sorry for that. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fc77cqxezjd_kkky38ghljnu-+t0zt0czogobvybnw...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Fri, Jul 19, 2013 at 8:48 PM, John Paul Adrian Glaubitz wrote: > On 07/19/2013 07:47 PM, Scott Kitterman wrote: >> John Paul Adrian Glaubitz wrote: >>> >>> On 07/19/2013 06:57 PM, Scott Kitterman wrote: >>>> >>>> sysvinit148865 99.83% >>> >>> >>> The reason might be that systemd does not conflict with sysvinit :). >> >> >> So are we playing word games now or trying to solve a problem? According >> to the popcon data, neither systemd nor upstart have enough deployment to be >> considered anything other than essentially zero. > > > I don't understand why anyone would assume that the popcon data in this > context is not accurate. > > Again, sysvinit is essential, systemd is not and it doesn't have any > reverse dependencies. Thus, every counted systemd installation was > actually actively performed. Oh, really? Because its the second time you claim that? apt-cache rdepends systemd --important --no-conflicts --no-breaks -o APT::Cache::ShowDependencyType=1 Granted, the rdependencies in stable/testing/unstable are all alternatives in the second position which can be easily solved otherwise. But we have also gnome-settings-daemon in experimental which depends without an alternative on it. Now, if you look really close on the popcon data for systemd you see that in March 2013 there is a plateau reached for systemd, which "suddenly" at the end of the month is followed by the constant up – which neatly alines with the upload of the previously mentioned gnome-settings-daemon to experimental with a systemd dependency. So, what do you think: More people wanting to testdrive GNOME 3.8 or systemd? Oh, and while you have the graph open: Do you see the bump in the graph at the end of May? Lets guess when the systemd survey was… so we can assume that "a lot" people installed systemd to test it for the survey and it worked so "great" that they not only not continued to use it, but have also actively deinstalled it again – even though you don't have to, like for upstart which doesn't seem to have obvious bumps (beside the ubuntu misreporting) so everyone installing it sticked with it… I will leave the obvious conclusion as an exercise for the reader. Of course, both analysis are obviously flawed as this popcon data can't really be interpreted that way as its an apple to banana comparison and way too few datapoints, but everyone likes misinterpret statistics as "proven" by this thread – and statistics say that I am a pro-faker! "I only believe in statistics that I doctored myself." -- Winston Churchill Best regards David Kalnischkies P.S.: Everyone who is now trying to disprove my "facts" has missed the point. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbmbdhcruh+m4k-6m3wvkg3pezm1ursg0jvbexd-jo...@mail.gmail.com
Re: Status of deb(5) format support in Debian
On Wed, Jul 31, 2013 at 6:56 PM, Stefano Zacchiroli wrote: > On Wed, Jul 31, 2013 at 06:24:32PM +0200, Guillem Jover wrote: >> Due to bug 718295, and in preparation to add non-gzip compression >> support for control.tar, I've tried to get an accurate view of the >> current deb(5) format support in software present in Debian. The >> resulting table looks pretty bad: >> >><https://wiki.debian.org/Teams/Dpkg/DebSupport> > > So, about the following passage on that page: > >> The current support seems quite bleak, and part of the blame goes to >> dpkg for not providing better interfaces for others to use, hopefully >> that will be remedied soon. > > Can you expand on the planned remedy and in how "soon" it might arrive? That I would be interested in as well. APT (or better: libapt-inst) is containing this tar stuff for two reasons: 1) apt-extracttemplates – which is a hack/layer violation as that is really something a dpkg-* (or debconf) tool should do but its still here… [Its on the roadmap for dpkg since at least 1.15.X (according to wiki).] 2) apt-ftparchive – used to generate Contents files (which seem to be slightly different from the ones dak is generating for all the cool kids). So, 2) we can ignore for now, 1) would be nice to fix as basically everyone has this one installed (and hence everyone has 2) installed), but "maybe" I will leave that bugreport open for a while just to see what happens… I know that everyone dreams about a stable API for a library, but I believe that even an unstable library at this point is way better than the status quo of having other layers like libapt (which is a proof that even if being unstable is a pain, the alternative would be worse – and that's a freaking C++ "library" …) providing makeshift replacements. There are e.g. a bunch of dpkg-style version-comparison implementations in Debian which should really just be a single one under the control of dpkg and that might be "just" ~5 because libapt includes one, so it could be misused by others (anyone remember the kernel depending on libapt-pkg-perl?). Best regards David Kalnischkies P.S.: Could the table be enhanced with a description for the table headers? I have no idea what an "ar slash" might be, and not really what LFS means as the format has no support for >10 character filesizes as far as I know. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fAaY2_L+mfbTtUU2T=wgl4whwbymh1ocjufyeztbek...@mail.gmail.com
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
On Fri, Aug 2, 2013 at 2:52 PM, Paul Wise wrote: > If so, here is the list of software that probably needs updating: > > dak > apt/apt-ftparchive > reprepro > launchpad > dpkg-dev > devscripts > derivatives census (c)debootstrap Also, apt-get is forcing MD5 in --print-uris by default because not doing it used to break all kinds of scripts. I think jigdo was one of them, no idea if that is really the case and/or if this changed by now. (not saying they shouldn't be fixed, just that the list is probably longer) > Side note; is SHA512 accepted/checked by apt in Release files yet? If > so it would be great if the spec at [2] could be updated for that. Yes, APT is supporting SHA512 in in/output, but more as a by-product of the SHA2 group as a whole than a specific feature. This, and a bit that APT is just one implementation of this "spec" is the reason that it isn't mentioned in the wiki. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbswkxvu5ugcw8qjnerfxfqp8azcfxj5otecf1zsnf...@mail.gmail.com
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
On Fri, Aug 2, 2013 at 6:33 PM, Ondřej Surý wrote: > On Fri, Aug 2, 2013 at 2:52 PM, Paul Wise wrote: > So, yeah let's drop MD5, but don't introduce neither SHA512 nor SHA-3 > unless there's a cryptographical need (there isn't at the moment). Actually, it might be less controversial to drop SHA1[0] as the MD5 has fieldnames (as Guillem already mentioned) which are probably assumed to be present. I have not check(-ETIME) that for APT now, but somehow I would be surprised if it wouldn't dislike (some) missing MD5 sections even if it isn't using the sections for providing MD5, but because they have a wonderfully stable name like "Files". Its not like we are anywhere near to a "cryptographical need" to drop MD5 (as you have to do (at least) two pre-image attacks in a row with the same file (aka compressed and uncompressed) – and as a bonus, the filesize has to match as well – not to mention that the file has to make sense…) and at the time we do SHA1 is probably not an interesting candidate. Best regards David Kalnischkies [0] expect in pdiffs as that is the only supported in there so far -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fBiOFv-S�tVvZ=Y+UJbNBCcd64f�vp7ybnkvos...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Wed, Sep 4, 2013 at 8:59 PM, Sune Vuorela wrote: > On 2013-09-04, Steve Langasek wrote: >> Unless apt has gotten smarter recently (which is not out of the question), >> no. It's a common misconception that apt will care about Provides/Replaces >> for selecting new packages on dist-upgrade, but while it seems like a nice >> idea, TTBOMK it's never been implemented. The policy defines two uses of Replaces: 7.6.1 Overwriting files in other packages – this is completely ignored by APT as that could be anything from "replacing a single file" over "fighting with this package over a few filenames" to "replacing all files". 7.6.2 Replacing whole packages, forcing their removal – there is the common believe that this allows all kinds of magic to happen, but no, it doesn't: The hole paragraph doesn't mention upgrades once, because there is no upgrade path. Not between mail-transport-agents, httpds, editors, "node", "git" or "mplayer" packages (random examples, no critic). So my simple question is, which combination of relations should that be that tells a smart package manager to upgrade pkgA to pkgB ? And does this combination also survives in the real world in which many maintainers e.g. still haven't got the difference between breaks and conflicts or depends, recommends and suggests? > Over in RPM land, I think they have a Obsoletes relation for a 'you > should consider this package a successor to package' APT has support for it since 2001. No idea how functional it is nowadays though as the apt-rpm fork from there this probably came is just as frozen. There should be a discussion about it in that timeframe, too. I remember seeing one at some point in my history-digging, can't find it now though. I think the most interesting point against such a relation might be: Package: aptitude Obsoletes: apt (Not that we would be in a fight, but many people think we are, so lets just add some fuel for them. KDE & Gnome works just as well) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fB_rmGTBPRYzu5HSJo_=eyigfqrlqtmzyh0ebjlg1u...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Thu, Sep 5, 2013 at 11:34 PM, Philipp Kern wrote: > On 2013-09-05 11:15, David Kalnischkies wrote: > [ Provides/Replaces up thread ] > >> The policy defines two uses of Replaces: > > […] > >> So my simple question is, which combination of relations should that >> be that tells a smart package manager to upgrade pkgA to pkgB ? > > > What about pkgB replacing and providing pkgA? Because its usually an error to just replace a package without breaking/conflicting against it in which case it looks suspiciously like 7.6.2 – also just take the examples I mentioned and think about what happens: For example, you made mplayer2 now an upgrade for mplayer. I am not sure that is what their maintainers/upstreams intend. (maybe it is, but I am not keen on letting foo2/foo-ng maintainer decide what is a good upgrade path for foo – that should really be decided by foo maintainer). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fd+bkrjnprzcdssgq3ar0z205o3h4eqpryi9zn0y_5...@mail.gmail.com
Re: Looking for ideas for merging a micro package...
On Fri, Sep 6, 2013 at 9:41 AM, Thorsten Glaser wrote: > In fact, I even demoted it from Recommends to Suggests on a package > because many people still run with install-recommends=true and it > was not strictly needed. Thanks for fixing a bug in your package. Just don't blame other people for your bugs next time. I "recommend" reading debian-policy (§7.2). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fc2vyjohizmar03yhrbuqsjt764vht0tl6vdai-vjl...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Fri, Sep 6, 2013 at 4:16 PM, Simon McVittie wrote:
> On 06/09/13 10:17, David Kalnischkies wrote:
>> For example, you made mplayer2 now an upgrade for mplayer.
>> I am not sure that is what their maintainers/upstreams intend.
>> (maybe it is, but I am not keen on letting foo2/foo-ng maintainer
>> decide what is a good upgrade path for foo – that should really
>> be decided by foo maintainer).
>
> In controversial cases, can't we avoid this by social pressure ("don't
> do that, it's rude")?
I should have noted that this was a bonus – the key point is that there
must be a way for foo2/foo-ng maintainers to declare that they provide
a (more or less) feature compatible replacement, and they do it with
exactly those relations as this is how debian-policy defines them, so
they can't be reinterpreted.
As we saw in "Debian Cosmology": You can easily change an init
system, but don't you dare to change a package manager …
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fdr8-oz0yfc6kqagmtmgi+a_5f+bc9fucwqtblnjs7...@mail.gmail.com
Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)
On Fri, Sep 6, 2013 at 7:05 PM, Steve Langasek wrote: > Now, maybe apt could consider a package a replacement only if pkgA > Replaces/Provides pkgB, *and* pkgB is no longer available. Are there cases > where that would give the wrong result? Is it practical to implement? Depends I guess on how much you value slight derivations from the norm. APT detects "obsolete" packages in its ProblemResolver and gives those a small penalty in conflict resolution, but I am not sure its a good idea to not only increase the penalty but let it cause actions by itself: Many people have multiple releases in their sources.list, so a package is not really disappearing – or takes quiet a while until it disappears. On the other hand packages sometimes disappear "temporarily" in testing. Also, sometimes packages disappear from stable – so while its a good idea to do something about those, I would say this is the wrong way of doing it as such an automated change contradicts stable. (and it doesn't work for the more common cases of packages which disappear, but have no replacement as such) What MIGHT (I haven't really though about it yet) work is limiting it to provides+replaces(+breaks) in the same source package, but I am not sure it makes that much sense to introduce complex rules for dependency relations if the current "simple" rules are already not understood by everyone (like breaks vs. conflicts). Personally, I would say we need a hints file just like britney and co have, but for package managers which tells them that this package is gone and a) can be replaced automatic by foo b) the user should decide between foo, bar, baz (this info is usually available in prosa in the RoM/RoQA bugreport) c) has no (free) replacement d) is no longer needed … Not that this would make the life of a maintainer necessarily easier, but it at least frees the user (and the package manager) from deciding if this remove requires user-attention or is just boring house-keeping. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fatnijufhoosqmencpjuozc-83mp7dmwmguzlajwdj...@mail.gmail.com
Re: [RFC] multiarch and virtual packages
On Thu, Oct 3, 2013 at 11:54 AM, Vincent Danjean wrote: > I tried several variation, adding :same and/or :i386/:amd64 to > the Conflicts and/or Provides in ICD Loader. I do not succeed into :same doesn't exist (in this context), where did you find that? Anyway, negative dependencies (Conflicts/Breaks/Replaces) effect all architectures and can't be limited to specific architectures currently [0]. [0] https://wiki.ubuntu.com/MultiarchSpec#Architecture-specific_Conflicts.2BAC8-Replaces > I see (not tested) one solution: to use one virtual package per > architecture (libopencl1-i386, libopencl1-amd64, ...) but this means to > generate the Provides/Conflicts/Replaces field at build time (using > subst vars). How about alternatives instead of this Provides/Conflicts/Replaces stuff to allow multiple loaders per architecture (and such an alternative is architecture specific by design). And could the virtual package maybe named 'opencl-loader-api-1' or something? Best regards David Kalnischkies P.S.: If you wanna play, try APTs testcases. :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fa25wbrofpp9w9e9mapxubt16uuh8zqcb3o15+_+sk...@mail.gmail.com
Re: Please assume good faith
On Fri, Oct 25, 2013 at 11:31 PM, Nikolaus Rath wrote: > Thorsten Glaser writes: >> Lars Wirzenius liw.fi> writes: >> >>> I write a backup program. It uses its own storage format, and people >>> sometimes ask if they could use tar files instead. But I am evil >>> incarnate and FORCE them to use my own storage format instead. Should >> […] >>> can be, and I think that the storage format I've developed is better >>> than storing backups in tar files. I truly, deeply feel that using my >>> format makes the program better, and that offering tar as a choice >>> would be pretty much disastrous, because almost all of the features I >> >> This *is* bad because if there is an existing userbase with tar (which >> isn’t true in the obnam case, sure, but would be true if you were to >> try forbidding all other backup programs in Debian) this will break >> their use cases, and *that* is what the systemd situation is all >> about. > > I don't understand this point of view. Even if there is an existing > userbase, I don't think that would obligate me (as the author) in any > way to support them in the future. […] You are not forced of course, but if you have (or aim to have) a userbase consisting of more than just a few people you might want to consider to not alienate them because you are a nice fellow (or aim to be one). A considerable amount of my volunteer work here in Debian is spent on keeping APT working even in the strangest usecases. I e.g. had quiet a few sleepless nights while trying to find a way to massage MultiArch into it without breaking too much. Others did similar things in other areas. If anyone involved would have a "I don't care about users" attitude we would probably still use ia32libs. And based on that we don't have enough people to maintain one APT¹, I doubt you find enough for two, so a "just fork it" sounds nice in theory, but just because you have a million users doesn't mean you have a million developers willing to work on it… That isn't meant to be advocating to never change anything, but you better have really really really good reasons to do it OR you accept that people start to distrust you and avoid you like the plague even if you have invented the cure for the common cold this time. You can think what you want about how Linus is communicating his points, but he earned quiet some credit with "we don't break userspace - EVER". And while we are at trust and communicating: We might want to consider admitting that "systemd" isn't an init system. 'Normal' programs like GNOME do not depend on an init system as much as they don't depend on a package manager. They depend on a certain userland, like GNU, BSD, Plan9, busybox or … yes, or systemd. It just happens to be that this userland contains also a binary which provides PID1. I think busybox has one, too. (And it also namespaces everything.) Best regards David Kalnischkies ¹ It's the only team I have personal experience with, but I guess you can pick any random Debian core/native-devel team and the sentence is still valid. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fcbsnpxdxjiuxkeuckqhxgrgrn7yguenzf1sbyl4ho...@mail.gmail.com
Re: Please assume good faith
On Sat, Oct 26, 2013 at 4:31 AM, Nikolaus Rath wrote: > David Kalnischkies writes: >> On Fri, Oct 25, 2013 at 11:31 PM, Nikolaus Rath wrote: >>> Thorsten Glaser writes: >>>> Lars Wirzenius liw.fi> writes: >>>>> I write a backup program. It uses its own storage format, and people >>>>> sometimes ask if they could use tar files instead. But I am evil >>>>> incarnate and FORCE them to use my own storage format instead. Should >>>> […] >>>>> can be, and I think that the storage format I've developed is better >>>>> than storing backups in tar files. I truly, deeply feel that using my >>>>> format makes the program better, and that offering tar as a choice >>>>> would be pretty much disastrous, because almost all of the features I >>>> >>>> This *is* bad because if there is an existing userbase with tar (which >>>> isn’t true in the obnam case, sure, but would be true if you were to >>>> try forbidding all other backup programs in Debian) this will break >>>> their use cases, and *that* is what the systemd situation is all >>>> about. >>> >>> I don't understand this point of view. Even if there is an existing >>> userbase, I don't think that would obligate me (as the author) in any >>> way to support them in the future. […] >> >> You are not forced of course, but if you have (or aim to have) a userbase >> consisting of more than just a few people you might want to consider to not >> alienate them because you are a nice fellow (or aim to be one). > > Yes, that's certainly what I do in practice. But I do not understand how > you make the jump from this to: > >> That isn't meant to be advocating to never change anything, but you better >> have really really really good reasons to do it OR you accept that people >> start to distrust you and avoid you like the plague even if you have >> invented the cure for the common cold this time. > > Is that really how you'd feel toward me if I stopped working on a piece > of software? By being nice to you for a limited time I get your distrust > and avoidance afterwards? I don't think that's a healthy attitude for > open source, because it means that if you want to get along with people, > you better not release any of your code in the first place (at least > everyone will still be neutral to you then). Maybe. The difference is how you have communicated what your software is supposed to achieve. "Just scratching my own itch here" is far different from "all your base are belong to us". You say later on that APT is doing what you need. Would you like that to change? Do you really think you could use an old version for long? (lets be crazy and announce that apt is hard-depending on bsd jails now) If you think trust isn't a healthy 'currency' in volunteer communities I wonder what you are using… I have the luxury of being able to delegate such (to me) ultimately boring decisions like which init system is allowed to start my tiling window manager to others I trust and are far more capable in that area. Others on this list obviously can't or we wouldn't have such a battle, so it might be interesting to find an answer why they can't and learn from it (beside from those who think fighting is fun maybe). As usual: "War does not determine who is right – only who is left." >> And based on that we don't have enough people to maintain one APT¹, I doubt >> you find enough for two, so a "just fork it" sounds nice in theory, but >> just because you have a million users doesn't mean you have a million >> developers willing to work on it… > > No, but that's really a problem (or non-problem) of the millions of > users. If no one is interested in working on apt, isn't that a sign that > apt is really good enough for most of its millions of users? > > At least this is the reason that I'm not working on apt. For me it works > perfectly, so I spend my time working on things that really bug me > rather than working on apt. That is nice to hear, but given that the answer to the question which package owned the last two open RC-bugs against Debian wheezy and which one has the most open bugreports in general in the BTS is "apt" I somehow doubt its true for everyone around here. Its more a sign for a) capable contributors believing that they have to be deities (pun intended) to work on APT, b) users trusting that those deities are not stabbing them in the back and c) the universal hope for having always at least one more active deity than deities hit by a bus… Lets just hope that works out just as 'well' as it does for other teams. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_faekqgz3xaydkrvpzgvuc5vqeczb8cvyj9+isttkxq...@mail.gmail.com
Re: Description-less packages file
Hi again *, given that my previous mail was dropped by every list expect debian-l10n-devel (which dropped it into moderation queue) [1] let me be offensive and just forward it to debian-devel again (as i haven't the time to bother [various] listmasters now) where at least Eugenes mail ended up, even through his was dropped by other lists, too… All i can say about that: "Et tu, deity@l.d.o?" debian-l10n-devel is properly right: Too many to-addresses… Best regards David Kalnischkies [1] http://lists.alioth.debian.org/pipermail/debian-l10n-devel/2011-November/001457.html -- Forwarded message ------ From: David Kalnischkies Date: Fri, Nov 4, 2011 at 21:22 Subject: Re: Description-less packages file To: debian-devel@lists.debian.org, debian-...@lists.debian.org, debian-rele...@lists.debian.org, de...@lists.debian.org, aptit...@packages.debian.org, debian...@lists.debian.org, debian-l10n-de...@lists.alioth.debian.org, debt...@packages.debian.org, dctrl-to...@packages.debian.org, debian-services-ad...@lists.debian.org, c...@packages.debian.org, synap...@packages.debian.org Hi *, First of all: Yeah! ;) On Thu, Nov 3, 2011 at 16:39, Joerg Jaspert wrote: > I just merged a patch from Ansgar to generate the Packages files without > the English description embedded inside them. Instead they are now > written into a new file, the "English Translation" file in > "main/i18n/Translation-en.bz2". They thus appear alongside all other > translated descriptions as "just another language". apt & co will (or > should) just download those Translation files to show the description, > as they do already for all other languages. Back in the good old days in 2009 [0] in which we discussed that feature my impression was that we want to remove the long description from the Packages files, not the complete description - mostly for compatibility reasons indeed, but having some sort of description available even without translations doesn't feel that wrong - at least for me. Anyway, the apt in squeeze supports the removal of long descriptions in the way it was described back then and is since recently used by ubuntu as I was told. The complete removal is NOT supported in a way that it will even do random stuff (aka segfaults) see #647590. The bugreport claims that aptitude works, which I personally doubt a bit as it should use the very same codepaths, but even if it would I assume that other libapt users are failing. I guess other applications/script make assumptions about the availability of a Description, too. So, long story short: Is this going to be the implementation ftp-master chooses for wheezy or are we getting a short description back? And while we are on it: Could we get i18n/Index (back) and have it look like a "normal" Release file instead of this ".bz2-only"-listing? (because apt/wheezy really uses it to avoid requesting not-existent files) Best regards David Kalnischkies [0] http://lists.alioth.debian.org/pipermail/debian-l10n-devel/2009-August/000507.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbargde_t0mof8jmuodmrxi0atd4dzqcbykxwf+xr4...@mail.gmail.com
Re: Managing left-over configuration files
Hi, in general, such questions are better suited for debian-mentors@, but here we go: On Wed, Dec 14, 2011 at 09:07, Malte Forkel wrote: > Am 14.12.2011 00:00, schrieb Malte Forkel: >> How do I properly handle the old control files? How do I tell a package >> that a specific file does not belong to this package anymore? I guess >> the same questions might arise when the set of control files changes >> with a new package version. > > I'm sorry. What I'm worried about are the "configuration" files owned by > a transitional package after an upgrade. So please > %s/control/configuration/g. May be I shouldn't try to ask questions > after midnight :-) I think what you mean is best described/covered with the advice to have a look at the manpage of 'dpkg-maintscript-helper', but i must confess that the question isn't all that clear to me with the 'sed' either. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fdzrfjgauif_jqpfs3kyzwl17+y29pwou2ajvslt2t...@mail.gmail.com
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Sun, Dec 18, 2011 at 18:56, Roger Leigh wrote: > On Sun, Dec 18, 2011 at 06:48:53PM +0100, Goswin von Brederlow wrote: >> Josh Triplett writes: >> >> > I disagree; I think it leads to a significant burden. Having /var >> > separate requires pre-determining an appropriate size for it, and that >> > will vary wildly between systems. At a minimum it needs enough space >> > for /var/cache/apt, which can grow to many gigabytes. Servers with mail >> >> Dude, run apt-get autoclean in cron daily. :) > > packages. I'm surprised it doesn't automatically remove > outdated .debs when you update, and require special configuration > not to do that. As you seem to know the one-size-fits-all sane default for the functionality implemented in apt's own cronscript, please report a wishlist with these values and i am sure we will be happy to incorporate it. And please provide a valid email address in this report so we can forward all messages complaining about these new default to you. While looking forward to your bugreport, Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fdtctf8vzg3eft9inozer1h5fhfnvm8h37lnmgk2yc...@mail.gmail.com
Re: Bug#652891: ITP: nerdtree -- Nerdtree is a vim plugin which gives a tree view of all the directories
On Sat, Dec 24, 2011 at 09:29, martin f krafft wrote: > also sprach Medhamsh [2011.12.24.0912 +0100]: >> Thanks! By the way I have started working on this and how >> do I get a mentor? Should I write to pkg-vim-maintainers? > > Again, your plugin should not be a package of its own, but submitted > as a patch to vim-scripts. There is already a bug+patch for it in the bts: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624661 So you might want to contact the author, update/check the patch and ping the maintainer(s) to get it included. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fdn17vt6hf7zscohlt4q4eacazf9dpdo1c_zb4nyxn...@mail.gmail.com
Re: Please test gzip -9n - related to dpkg with multiarch support
On Thu, Feb 9, 2012 at 22:29, Guillem Jover wrote: > On Thu, 2012-02-09 at 21:50:17 +0200, Riku Voipio wrote: >> On Thu, Feb 09, 2012 at 03:34:28AM +0100, Guillem Jover wrote: >> > Riku mentioned as an argument that this increases the data to download >> > due to slightly bigger Packages files, but pdiffs were introduced >> > exactly to fix that problem. And, as long as the packages do not get >> > updated one should not get pdiff updates. And with the splitting of >> > Description there's even less data to download now. >> >> off-topic but often pdiffs don't really speed up apt-get update. Added >> roundtrip time latency on pulling several small files slows down the >> download unless you run update nightly. > > One of the reasons of this I think, is that the current pdiff > implementation in apt is really not optimal, see #372712. The real slowdown is that APT currently works on one pdiffs at the time. The solution for this is two-fold: First get all pdiffs needed - for debian this is easy as its strictly sequential, but other archives can (and some even do) use different paths so we need a bit more metadata to support these, too. After we have all these pdiffs we can merge these to one "big" pdiff and apply this one. As we walk over > 25 MB files only once and not for each patch we should be quiet a bit faster. The theory and even python code for the merge part can be found at [0], it's just that the APT team is since years so overcrowded that we haven't yet decided who can pick this one [/irony]. If someone wants to work on that, feel free to drop a line to deity@l.d.o (and to Anthony) and i will try to help if time permits. [0] http://lists.debian.org/deity/2009/08/msg00169.html >> But the more interesting slowdown is that the amount of packages is general >> slows down apt operations in a rate that is around O(dependencies^2) (pure >> guess, >> perhaps someone has better knowledge?). My question would be why you are guessing O(d^2) for a situation which should be intuitively a O(d*2). My empirical testing seems to support this, given that the runtime roughly doubles (a bit less) (Less than doubled packages as we have arch:all packages, but a bit more than doubled deps given that we have new implicit ones for multiarch). But as team member and implementer of multiarch in APT i might be a bit biased here… ;) (note though that numbers/timing are based on experimental, sid has currently a slightly different implementation, but shouldn't be that bad either) >> We do remember apt-get slowing down >> to crawl on maemo platforms with much smaller repositories.. As an owner of an N810 i am not, but i might be used to pain, given that i managed bootstrapping Debian with a recent (partly working) kernel on it (the gentoo/openwrt have details on that if someone is interested). So if you can go into details what you remember exactly we might be able to work on it - until then, my only comment to adding more packages: "What should possible go wrong?" ;) If APT survives i386 packages in amd64, it might survive some new ones, too. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fa8ujbu23_4qqhlqrcgmiu35mcsifk+d-vh-msqg2s...@mail.gmail.com
Re: Multiarch file overlap summary and proposal
ns on
difficult-levels on changing this in APT but i guess its relatively easy.
(the only problem i see is that i don't have ${source:Version} available
currently in the version structure, but we haven't even tried pushing
apt's abibreak to sid specifically as i feared "last-minute" changes…)
The question just remains if it is a good idea…
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fD4LAdNF=amxlewbcxbngveayadgiw+hfrie-ksh3m...@mail.gmail.com
Re: Multiarch file overlap summary and proposal
On Thu, Feb 16, 2012 at 09:26, Goswin von Brederlow wrote: > Russ Allbery writes: >> David Kalnischkies writes: >>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote: >> >>>> Actually, why would that be the behavior? Why would dpkg --purge foo >>>> not just remove foo for all architectures for which it's installed, and >>>> require that if you want to remove only a specific architecture you >>>> then use the expanded syntax? >> >>> We (as in APT team and dpkg team) had a lot of discussions about that, >>> see for starters (there a properly more in between the 10 months…) >>> [0] http://lists.debian.org/debian-dpkg/2011/01/msg00046.html >>> [1] http://lists.debian.org/debian-dpkg/2011/12/msg5.html >> >>> In short, i think the biggest counter is that it feels unintuitive to >>> install a library (in native arch) with e.g. "apt-get install libfoo" >>> while you have to be specific at removal to avoid nuking 'unrelated' >>> packages with "apt-get remove libfoo". >> >> Ah, hm... I suppose that's a good point, although honestly I wouldn't mind >> having apt-get remove libfoo remove all instances of libfoo that are >> installed. I think that would be quite reasonable behavior, and don't >> find it particularly unintuitive. >> >> I agree that it's asymmetric. apt-get install libfoo means libfoo:native, >> but apt-get remove libfoo means libfoo:*. And asymmetric is bad, all >> things being equal. But I think this may be one place where asymmetric is >> still the right thing to do; I would argue that it means you're >> implementing the most common operation in both cases. apt-get install >> libfoo generally means "give me a native libfoo" since non-native libfoo >> is going to be an unusual case, and apt-get remove libfoo generally means >> "I have no more interest in libfoo, make it go away." I think that people >> who want to get rid of one architecture of libfoo but keep the other are >> already going to be thinking about architectures, and it's natural to ask >> them to qualify their request. > > In another thread we discussed the problem with plugins (e.g. input > methods for chinese/japanese) and LD_PRELOAD (e.g. fakeroot) using > stuff. For those packages it would be great if > > apt-get install plugin > > would install all architectures of the package (for various values of > all :). This would add asymetry in that apt-get install libfoo would > sometimes mean libfoo:native and sometimes libfoo:*. Having apt-get > install libfoo:* for anything M-A:same would make it more symetric in > that case. > > "apt-get install libfoo" generaly means "please upgrade libfoo to the > latest version". That should be "apt-get upgrade libfoo" which doesn't > yet exists. Libraries should be pulled in from binaries and not > installed manually so I wouldn't give that case much weight. But M-A:same will end-up on dev-packages as well, and these are quiet likely to be installed manually. And in the end are libraries more often installed by hand then they are removed - think e.g. of the binary distribution of certain applications (aka mostly games). I need libfoo for my new amd64 game so i install it. Later i remove the game and remember to remove libfoo with it also. I just forgot that i have a i386 game i play from time to time which requires libfoo:i386 which is killed by that, too. That i haven't packaged my games is misfortune, but we are talking about real-world usage here… Also, in some distant future we might be able to co-install binaries. It's easy to think of M-A:same just as libraries but i personally think that this is an unnecessary mental limitation and just exists because it is currently the (mostly imaginative) case. And it seems like you assume apt-get and co are only used by humans. In fact i think it is at least equally common used in scripts, usually with -y to e.g. remove obsolete packages. I can't wait for the resulting shitstorm… (btw, you know that 'apt-get purge foo+' is possible, right? Which behavior would you expect? The same as 'apt-get install foo' ?) The "same-as" thing in the plugin thread just smells like poor-man's conditional dependency - and it's trying to solve something which isn't solvable on that level: Just because i have armel packages installed on my system doesn't mean that i am going to execute an armel binary. Cross-building for example will install libc6:armel for me, but i am still not even close to be interested in libfakeroot:armel. To get libfakeroot:armel on the
Re: Multiarch file overlap summary and proposal
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 quote it.
:all is already an architecture and currently it seems like dpkg accepts
only that while APT will accept :amd64 (or whatever is native), too,
partly for internal reasons, but also because the difference for an apt-get
user is not really important. Either way, overloading wouldn't be nice.
:any has a special meaning in build-dependencies already meaning - surprise
surprise - give me any package. Overloading would be uncool, beside that
its the wrong word for it anyway if you want all, and not just any package.
>> > Actually, why would that be the behavior? Why would dpkg --purge foo not
>> > just remove foo for all architectures for which it's installed, and
>> > require that if you want to remove only a specific architecture you then
>> > use the expanded syntax?
>>
>> We (as in APT team and dpkg team) had a lot of discussions about that,
>> see for starters (there a properly more in between the 10 months…)
>> [0] http://lists.debian.org/debian-dpkg/2011/01/msg00046.html
>> [1] http://lists.debian.org/debian-dpkg/2011/12/msg5.html
>>
>> In short, i think the biggest counter is that it feels unintuitive to
>> install a library (in native arch) with e.g. "apt-get install libfoo"
>> while you have to be specific at removal to avoid nuking 'unrelated' packages
>> with "apt-get remove libfoo".
>
> I would expect this (especially if the package foo is not a library, but
> I would also expect this for libraries):
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 future-coinstallable binary.
And the foo:* default would be okay and intuitive for all of those?
You also skipped the part of backward-compatibility with tools which
expect a single line/stanza of response and commands like
dpkg --{get,set}-selection which by definition work only with a single
package.
And backward-compatibility means in this context also to support
a dist-upgrade from squeeze to wheezy. If a new version of dpkg
doesn't accept the 'old' commands APT uses the upgrade will
be a pain.
The two threads i mentioned contain a lot more of these
considerations, so it might be in order to read these before
coming up with 'new' ideas.
> * apt-get remove foo removes all installed foo packages (on all
> architectures).
More of a theoretical nitpick, but this was never the case.
apt-get pre-multi-arch handled only packages from native arch (and :all),
so if you had installed foreign packages with dpkg --force-architecture
apt-get would have ignored it, not removed it.
> This summarises how apt without multi-arch handles this, the above would
> make apt with multi-arch also behave so:
>
> apt-get install foo
> --->
> foo is not installed foo is installed
> apt-get remove foo
> <---
Is 'apt-get remove foo+' then going to install all foo's or just one?
The current implementation of always foo == foo:native doesn't fail
your diagram, too, so what is this going to show us?
>> (the only problem i see is that i don't have ${source:Version} available
>> currently in the version structure, but we haven't even tried pushing
>> apt's abibreak to sid specifically as i feared "last-minute" changes…)
>
> I'm not sure if you meant this with "Source tag", anyway, the 'Packages'
> files miss the source version too, but this could be added as optional
> field that would be used if it differs from the 'Version:' field.
It's already in for quiet some time ('current' sid amd64, first hit):
Package: 3depict
Source: 3depict (0.0.9-1)
Version: 0.0.9-1+b1
[…]
It's used in other places in APT, e.g. 'apt-get source', which just looks
at the Packages file stanza. That's fine as this isn't a speed critical
operation - but if we want it for the lock-step operation apt needs that
piece of information in its internal structures for fast access to it and
adding new fields in these structures will require an abibreak.
That's the intended meaning of the quoted sentence.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fB3CeUcFuue1CjPbkqoHNaSvaKt8Q=imgfx4uqmw_m...@mail.gmail.com
Re: Multiarch file overlap summary and proposal
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 future-coinstallable binary. >> And the foo:* default would be okay and intuitive for all of those? > > Yes, the foo:native default for installation and foo:* default for > removal would be intuitive for all of those. > > See [1] for a mental model. > > Hope that helps, > Jonathan > > [1] > http://thread.gmane.org/gmane.linux.debian.devel.dpkg.general/14028/focus=14031 Why would it be intuitive to add a specific value for the arch attribute with apt-get install foo # arch |= native but remove all values of the attribute with apt-get remove foo# arch &= ~all-architectures ? Isn't it more intuitive to have it this way: apt-get remove foo# arch &= ~native ? Maybe we just have different definitions of intuitive. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbq6z7tj1slohgs0kwh+xocsa_xjcvq+zs2omg3_y1...@mail.gmail.com
Re: Multiarch file overlap summary and proposal
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 centric. All I wrote was
> (in other words), that we should consider non-library packages as much
> as library packages, and I did not write nor implied that libraries
> should be handled in a different way.
>
>
>> Is 'apt-get remove foo+' then going to install all foo's or just one?
>
> "apt-get install g+++" is a weird syntax.
But its a syntax we support since basically ever and comes in handy
if you want to tell APT to not choose a specific alternative
(or disable specific recommends, …) without holds.
aptitude supports a few more of these modifiers (e.g. &) btw.
> The above shows that it seems to depend on the availability of
> foo:native if apt-get remove foo removes foo:foreign.
It's the availability of the native (or for that matter: most preferred arch)
which 'changes' this behavior. As tendra is not available for amd64 its
a pretty fair guess that i386 was meant and - as the result would be an
error otherwise - install it.
It's removed with the same command s/install/remove/.
A similar guess isn't done for removes in case the native is not installed
(but available and foreigns are installed) as it is a destructive command
(beside that it would fail the s/remove/install/ test).
See also the arguments against the
"foo == foo:whatever provided that whatever is unique"
in Raphaels mail in thread [0] mentioned above.
And as i said, its not only about apt-get install/remove.
It would be nice to have an approach usable for the various
commands of apt-mark and apt-cache, too.
(bonus points if it doesn't break usage with dpkg completely)
> # dpkg -l | awk '$2=="clang"{print}'
> ii clang 3.0-5 Low-Level ...
>
> # dpkg -S bin/clang
> clang: /usr/bin/clang
> clang: /usr/bin/clang++
>
> # dpkg -r clang
> dpkg: warning: there's no installed package matching clang
The last one is an inconsistency in what dpkg should do.
If i understood the outcome of thread [1] above right dpkg
doesn't want to arch qualify packages for which only one package
can be meant. I personally think this is misfortune, but so it be.
APT can't do this as while you might have only one installed at a
time you can still jungle with different archs in one apt command
so we need differentiate here.
Long story short, 'apt-get remove clang' fails, yes, but you have
it installed with 'apt-get install clang:i386' so we are at least
consistent (see foo == foo:whatever).
I could have a look at printing a notice through to be nice…
> # dpkg -l | grep libzookeeper-st2
> ii libzookeeper-st2:amd64 3.3.4+dfsg1-3 Single ...
> ii libzookeeper-st2:i386 3.3.4+dfsg1-3 Single ...
>
> Unlike the above dpkg -l output showing the foreign clang package,
> libzookeeper-st2 is shown with the architecture appended.
dpkg prefers users which are specific if they refer to a M-A:same package.
It allows no arch as ~ 'installed' arch, but mostly only for backward-
compatibility as apt/squeeze obviously doesn't know about that new
requirement.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fdgs4zegelof9sb8-r-nfur2zo5bcjy0_8zpqfrfyz...@mail.gmail.com
Re: thoughts on blocking and downgrade attacks agains secure APT
source is still a trusted one and provided that you have a correct setup there is no "wrong" version chosen but a "less preferable" version. Yet, less is still more than nothing and there is only a certain limit in how much you can protect yourself against replay-attacks in this context in general. > And I really mean error,... IIRC APT and aptitude both generate warnings > if a repos or some files are missing, but who's reading this (especially > when something is scripted)? Mhh, yeah, in this case you shouldn't use scripts and/or read more. Really, if you care for security, but are unwilling to read a few lines of output we can't help you. It's like saying you are frightened that you might drive over a red stop light but are unwilling to look if the light is red before driving over the street… A script can check for exit codes or work with grep or alike - or you are going for python-apt to directly control what you do. Either way, someone has to read that - and another has to trust that the reader did a good job. > But it seems to me that this is not yet used by the clients, is it? > Generally I'd say, that (from a security point of view) really ALL > clients (APT and all ifs tools, aptitude, etc.) should stop working if a > single repository is out of date. That is the case currently and many people consider this a bug arguing that this a deny of service attack. I personally tend to agree to this, but have many more problems to work on than, so if someone really wants that changed it's properly faster to provide a patch… (or buy me a beer - my todo list tends to be open to bribery… ;) ) > Even for tools that just list some status (e.g. apt-cache) old data may > be a security problem, as we can never know by which way the output is > processed by users. I disagree. Old data is still valid data and the information is correct for what APT knows and correct in terms of what apt-get will work on. How should APT know that the future already arrived on everyones computer - expect yours, of course? In the end, the command is called *cache* and not *realtime*… In a way you happen to work always on old data. Sometimes it is just not-yet replaced by newer data… > In principle I'd be willing to open bugs for the above but given that > the impact is quite big and quite a lot is affected and I may not yet > even see the whole picture,... I thought it would be better to first > have a discussion with the experts on d-d. Please fill bugs if you have specific problems - this mail is quiet long, yet very unspecific and many aspects either wrong or unreproducible. That's frustrating for a developer and also frustrating for you as i can't answer in a satisfying way. Also, if you really want to talk to experts in regards to specific packages, it's a good idea to contact the specific maintainer(s). Just because APT is a debian native tool (unfortunately) doesn't mean that all debian developers are experts on it. It just means that (hopefully) some debian contributors (yes, not necessarily developers) are upstream for this package. In your case de...@lists.debian.org has the experts (but i should warn you: 1. this is not a big army 2. you might end up talking to me again 3. not every front-end has a representative on that list 4. it's not high-traffic, but sometimes too much to answer all (3) might not be true through as we have way more front-ends than front-end developers…) Hope this helps a bit. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fCyhKQyn9MQ3LznjfrTcK9Bzr_5QXp_4Si2fHbVHOuY=a...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer
wrote:
> algo,... not to mention that newer algos like Keccack are quite fast.
I wonder if it is really a good idea to search for a security checksum
based on the metric that it can be quickly calculated … but off-topic.
>> To use your example of dpkg file checksums, their purpose has _nothing_
>> to do with security.
> Well their _intended_ purpose,.. that's right.
> But nothing keeps people from using it a security manner (e.g. by
> replication it to a "secure" remote node or so) and in fact... e.g.
> rkhunter already has a mode where it uses DPKG directly.
I think adding "better" checksums here would just encourage people to
think that they could be used in a security relevant way.
And carrying bigger/more checksums around just means that we waste
everyones diskspace to keep up the illusion of security for some people.
> Anyway... I guess it was clear, that I rather meant secure APT... dsc
> files, Release.gpg, etc. pp.
APT will usually negotiate the checksum to use based on what it supports
and what is included in the Release file.
Supported is currently in squeeze (in wheezy):
MD5, SHA1, SHA256(, SHA512)
Usually found in a Release file is currently:
MD5, SHA1, SHA256
so it will take SHA256 and be done with it. apt-ftparchive/wheezy will
generate SHA512 by default as well, I am not sure about dak or others,
but that isn't really a problem just yet.
This falls apart of course as soon as RSA (or whatever ftpmasters will use
in this dystopia) is broken, but I guess we have a problem then anyway.
So dropping MD5 and/or SHA1 would be okay I guess, note through that
apt-get --print-uris outputs md5sum by default as some scripts can't cope
with other checksums. See #576420 as an example why, so you would need
to find and fix these scripts first I guess (or just break them of course).
There is one exception: pdiffs work entirely with SHA1, were is some work
pending on the dak side, I guess while incorporating them into APT we could
work on that. In case of an emergency you could just disable that optional
feature of course (user as well as server side). And in the end of all days,
really interesting is only a pre-image attack, collision is kinda boring …
Oh, and there is "Description-md5". I can't imagine a scenario in which it
would be useful to change the English description of a package for an attack
(which you want to hide by displaying the translations of the not modified
version), but feel free to be the first to launch a successful pre-image
attack on long descriptions (with the "side" problem of not changing size
and checksum of the [compressed] Packages file including the description).
Beside, for Debian this "attack" becomes easier now as the translation is
split out and the md5sum therefore pre-calculated, so you can write whatever
you want in the Translation-* files as a description without caring for
Description-md5 ("side" problem still applies though).
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fAgOpwsdmmjZXm5P_UocZ0CjEsx=ohoe2gg_rybwnc...@mail.gmail.com
Re: Backports upgrade policy (ButAutomaticUpdates:yes)
On Thu, Jan 24, 2013 at 6:39 AM, martin f krafft wrote: > I think we ought to revert this change and turn off > ButAutomaticUpgrades for the backports archive (and update > apt_preferences(5)). You can find much of the same discussion in the bugreport requesting implementation of this feature in APT: #596097 In short: If you followed the recommendations in previous releases you were already used to this kind of behavior, so this flag just makes it way easier to reach the recommend mode of operation. Real world feedback over the years has convinced me this is a good mode to have as default for backports, regardless of the drawbacks it has as the alternative default is worse if not managed carefully. (but as I said two years ago, not my decision either way) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fawem6tkwltyr+-0oj5m-h+gaabqvecgg3v3+gkmp+...@mail.gmail.com
Re: Backports upgrade policy (ButAutomaticUpdates:yes)
On Fri, Jan 25, 2013 at 2:19 PM, Henrique de Moraes Holschuh wrote: > On Fri, 25 Jan 2013, Wookey wrote: >> +++ martin f krafft [2013-01-25 16:06 +1300]: >> > also sprach David Kalnischkies [2013.01.25.0020 >> > +1300]: >> > > You can find much of the same discussion in the bugreport requesting >> > > implementation of this feature in APT: #596097 >> > >> > Thanks for the pointer! I missed this discussion un^Wfortunately. >> > Anyway, it seems that most people are in favour of this change, and >> > your message pretty much sums up the reasons. >> >> You message was not usless as I never knew about the 100 < P < 500 >> feature, and the need to pin/not pin according to what effect you >> wanted vs AutomaticUpdates setting. Making this info more widely known >> would be a useful service so that people get the behaviour they want. >> >> (maybe it already is and I'm the only one no-one told, but I doubt it >> :-) > > Sorta. It is in manpage apt_preferences(5), but... > > Now, complete documentation of the Release files, where the tags you can use > in repositories to get such nice functionality like ButAutomaticUpdates... > Does anyone know where such a thing might dwell? Assuming s/Now/No/ … apt_preferences(5) is in fact the most complete documentation on this matter as there are only these two flags in regards to pinning (the other "special" values for pinning should not be made available to repositories as I described in the original bugreport). If you on the other hand mean what a Release (and various other) files can generally contain I would refer you to the discussion we had last year in May on debian-devel. You can delve into it from #481129 and #671503. WIP-Result: https://wiki.debian.org/RepositoryFormat If I remember correctly the short version is: Having an ftp-master approved debian-policy appendix defining this would be very welcomed, but needs input from various teams which already have no time to work on all the tasks they already have … :/ Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbpowwn6pf1blcqg3dcvrfixg3_jobozpm3orqj3m2...@mail.gmail.com
Re: Splitting the devscripts package
On Mon, Apr 1, 2013 at 2:41 PM, Benjamin Drung wrote: > Am Sonntag, den 31.03.2013, 00:13 + schrieb Ben Hutchings: >> On Sat, 2013-03-30 at 22:49 +0100, Benjamin Drung wrote: >> > Hi, >> > >> > devscripts ships a bunch of scripts to make the life of a Debian Package >> > maintainer easier. Not every script in there is Debian packaging >> > specific. Some of them are used on other non-Debian-based distributions. >> > I was contacted [1] and asked if we could split the Debian packaging >> > specific scripts from the rest. >> > >> > I like to keep only Debian packaging specific scripts in devscripts (see >> > the list below). Where should we put the non Debian packaging specific >> > scripts? Should we create a neutral project or are there other projects >> > in which these scripts fit? >> >> There is no reason why Debian couldn't continue to be upstream for >> these, but hosting on freedesktop.org might make them more visible to >> other distributions. >> >> [...] >> > Debian packaging specific scripts >> > = >> [...] >> >> These might usefully be further divided into truly Debian-specific and >> dpkg/apt-specific, at least in binary packages. > > What would this additional split give us as advantage? Are there > distributions that use dpkg/apt, but are not Debian derivatives? There is apt-rpm which is a pre-0.6 apt fork used by some distributions as their only supported package manager (the later according to wikipedia). [version 0.6 marked the introduction of apt-secure … on Christmas 2003] I have neither looked at the distributions nor at the scripts, so I have no idea how (un)useful they will be and/or if they even work on apt << 0.6. I am just saying that APT presence is not limited to Debian derivatives … Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fAvAc72z==4j=tokann6tvrgs9bmsgczj-hnq5y8xf...@mail.gmail.com
Re: Community Outreach to other communities
Hi bro Paul, thanks for your valuable contribution to fix the longstanding bug #271810 while outreaching to bro's at the same time! On Mon, Apr 1, 2013 at 4:41 PM, Paul Tagliamonte wrote: > I've attached a patch for apt to help us be more inclusive to this > critical market. Contrary to bro Arno I have to reject the patch in its current form though: 1. It opens a security back^Wfrontdoor: Given that cow has no forehead everything could enter her head without verification. I don't think we should be THAT open-minded … 2. The glasses seem to be an embedded copy as they are loosely coupled with the head without requiring physical attachment to the ears which is not possible with the glasses I have here, so these must be a locally modified version. Alternatively I would look into changing to a bronocle… äh, I meant monocle of course. 3. As with other cow suggestions: License? Source? And very important: How old is the cow? (It's a nude art after all) 4. As Arno suggested, contact us at de...@lists.debian.org – otherwise your NMU looks more like a NBU (non-bro upload) As a sidenote: I love that a cow is chosen to represent the bro movement even though some will be offended (not because of the gender or because she is missing a leg, those dipshits are not bros, I mean the BBQ-bros)! Thanks again bro and best regards David Kalnischkies on behalf of the APT bros -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fa_nhii99w97ung5qy8nc20t48wfhlcic6afevdodt...@mail.gmail.com
Re: missing libgl1-mesa-dri in upgrades
On Mon, Apr 1, 2013 at 11:16 PM, Daniel Pocock wrote: > On 01/04/13 22:04, John Paul Adrian Glaubitz wrote: >> On 04/01/2013 09:59 PM, Daniel Pocock wrote: >>> Agreed, but that doesn't complete the picture, as libgl1-mesa-glx >>> doesn't depend on libgl1-mesa-dri: >>> >>> $ apt-cache depends libgl1-mesa-glx >>>... >>> Recommends: libgl1-mesa-dri >>> >> >> Well, "Recommends" are installed by default, aren't they? However, I'm > > Not during upgrade or dist-upgrade operations. This is specifically an > upgrading issue. From man apt-get: > > " upgrade: > ... under no circumstances are currently installed packages removed, > or packages not already installed retrieved and installed." Correct for apt/squeeze, partly-wrong for apt/wheezy (since 0.8.15.3). A package requiring a new recommends which is in a non-broken policy state previously will be held back just like other packages requiring a new depends in apt/wheezy. In apt/squeeze the policy will break, which you could fix with "apt-get install --fix-policy", but that is going to fix ALL recommends. We are going to be "fine" in this regard as many packages have a new dependency in a new release (upgrade is mostly for between releases). In this case it is at least "multiarch-support". > "dist-upgrade: > ... intelligently handles changing dependencies with new versions of > packages" dist-upgrade on the other hand installs new recommends since the introduction of recommends. Keyword is "new": If you had recommends disabled previously and/or removed a recommends apt will not install this recommendation again. (It compares the recommends list of the old version with the new version and only uninstalled recommends present in the new, but not in the old version are marked for installation). Of course, if the recommends isn't installable you will still get a solution which doesn't include this recommends which will be displayed as usual. You have to install it later by hand then as it now an old recommends … (In stable, uninstallability shouldn't happen though) I guess the confusion comes from the word "dependencies": In APT namespace "dependency" means any relation which is allowed; not just a "Depends". So the sentence should be read as "… handles changing Pre-Depends, Depends, Conflicts, Breaks, Replaces, Provides, Recommends (if enabled, default yes) and Suggests (if enabled, default no) with new versions …" (for the sake of completion: Enhances are not handled) It's just that a user shouldn't really be required to know what those are. (if you digg deaper [usually in non-user facing texts] you will come across "hard", "important", "soft", "negative" and "positive" dependencies to complete the confusion. I will leave it as an exercise for now which subsets are meant with those adjectives) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fbnekgfnc+rpxj-63txu5s-kjq3yjroxomujf7rpoc...@mail.gmail.com
Re: Automatically satisfying Build-Depends from local control file
On Thu, Apr 18, 2013 at 12:07 PM, Marc Haber wrote: > On Wed, 17 Apr 2013 14:05:47 +0900, Charles Plessy > wrote: >>The tool you are looking for is "mk-build-deps" from the package "devscripts". > > So one uses mk-build-deps to create a .deb containing the build > dependencies as binary dependencites, put that .deb into an local > aptable archive, run apt-get update and apt-get install $PACKAGE. > > Am I the only one who thinks this is terribly backwards as compared to > hand-editing dpkg-checkbuildep's output to an apt-get install command > line? Michael actually blogged very recently about $ gdebi debian/control see: https://mvogt.wordpress.com/2013/03/22/using-gdebi-to-install-build-dependencies/ (but other highlevel-frontends might have similar "hacks" implemented) Of course we would like to have that directly in libapt but it is a hell of a lot of work to do it cleanly so that the frontends can actually use it. squeeze deeply wounded the "mmap ran out of room" error and wheezy should include fixes for remaining segfaults caused by growing caches, so the next waypoint on the road to never-ending glory is an interface to add structures to the cache after it is built which is a bit harder than it sounds as currently everything which deals with parsing is hidden (for reasons as the codebase supports different indexes for parsing; beside deb, there is an old out-of-tree rpm and new inventions like the immediate format EDSP). On the pro-side, if that's finally done we can do a lot of funky stuff. I wouldn't dare to hold my breath until then though, way too much stuff creeps up on the bug side to even try to implement new bugs^Wfeatures. (And no, pushing this as GSoC/OPW project isn't really an option) Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_faj16uq0ynm+6n9snetqpp4k9stxpsxms7we56dnf-...@mail.gmail.com
Re: Aptitude best to ignore a dependency
Hi Kevin, your question is better suited for one of the various support channels. Including but not limited to the debian-u...@lists.debian.org mailinglists, which are even available in different languages. Some quick answers anyway: On Thu, Apr 18, 2013 at 11:42 PM, Kevin Chadwick wrote: > Does this work and is aptitude the best way to update whilst ignoring > incorrect or even debatable dependencies or can apt-get do so too. The best way is to not choose this way. Or any other way suggested in this superuser thread. Packages usually have dependencies for a reason, not just because the maintainer is bored and wants users to waste diskspace, so ignoring them temporary is really bad, but in extreme cases might be necessary (hence, dpkg has a force option for it). Trying to ignore it for longer is a good way into misery and nobody will be able to help you (expect with a suggestion to reinstall system). So APT isn't even trying to offer an option (and I somehow doubt aptitude will do what you "expect"). > Is equiv a fast and easy solution? Its "fast and easy", I am not so sure about the "solution" part. > Currently I am getting fix broken on steam-launcher which wants > jockey-common -> polkit I heard that someone created a debian package (out of the ubuntu package) for steam, but I am not really interested enough to remember details, sorry. Most if not all of this stuff steam depends on should be available in debian, too, it will "just" have a different package name, so you really want to find out the names, not just fake the existence with equiv – steam will still require whatever the dependency provides, so it needs it installed and not just a fake package without content. > Also shouldn't security updates for existing packages update in any > case. What if something broke and the user didn't notice (background > task)? APT goes from one consistent system state to another. If your system ever reaches an inconsistent state you will usually have bigger problems than a pending security update as your system might not even boot anymore. Needless to mention that a background task can't just break your system, the user has to take some form of action to do it (like kill dpkg/APT while running, power outage, …) So you really want to fix this situation and reach a consistent state, from there you can easily install pending updates again. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fa7p72ri3rbvkgjyz5xu726f1ndukw5iusjzjxdedb...@mail.gmail.com
Re: epoch fix?
On Thu, May 9, 2013 at 11:43 AM, Philip Hands wrote: > I presume it's OK to add the implicit 0: to non-epoch depends? No, that not okay. dpkg rewrites versions at times – mainly in /var/lib/dpkg/status – to a "canonical" form, so this information is lost at some point. Especially does it cause "strange" behavior in APT: The records in the Packages file (aka with 0:) will be different from the records in the status file (aka without 0:) so APT will think the records talk about two different versions of the package (as the dependencies are different). Example: Package: foo Filename: foo.deb Depends: bar (>= 0:0.00-0) Package: foo Status: install ok installed Depends: bar (>= 0.0) (And before someone asks: wontfix in APT for performance and code duplication with dpkg reasons, among others) In my eyes it would actually make sense to rewrite the version in a "canonical" form already at package creation time and warn in lintian if a version wasn't written in the "canonical" form (as this usually indicates a misunderstanding/bug already). Only problem I see with that is that dpkg isn't providing an interface for it so far which lintian could use. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fDVRw__N_qyeo=vrask96l79l535ifhthw_ctu-54w...@mail.gmail.com
Re: idea: generalized soft dependencies
On Wed, May 8, 2013 at 8:51 PM, Eugene V. Lyubimkin wrote:
> Soft-Depends: a {90%}, b (>= 1.2) {20%}, c (>= 4) {99%}, c (>= 6) {70%}
If we assume its already hard to decide "recommends" or "suggests" it will
be impossible to choose a number between 0 and 100. Basically we are rating
likelihood of usage here and while the one provided by "a" will be a
common one for many, I am not up to the task of deciding if it will be
used by 90%, 80% or "just" 70% so naturally numbers will be assigned at
"random", which in turn means as a user I can't say: hey, install if
>= 70/80/90 as it means something different for everyone.
> Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
So supposedly on 50% of all desktops iceweasel is installed which can
in turn be used by the software having this dependency. Great, but I still
have no idea why 50% installed it and 50% don't.
Which 50% group I am part of? The tag desktop might give a hint, but
such tags need to be defined and carry a meaning. A tag like "laptop"
tells me that it will help with powersaving (which would probably be the
better tag name, as I will like want to install it on my phone too),
"printing" is useless if I don't have a printer, "online" and "streaming"
might not be the best ideas if I have no internet connection at all …
That's a lot harder of course, but caries way more useful information as
I have no idea how many people don't have their own nuclear power plant,
highspeed internet or a printer. 30, 50 or 90% ? I might be able to answer
that in my area (and I would probably still be wrong), but not on a global
scale.
> Soft-Depends: debdelta {10%,text:"to enable automatic delta downloading"}
While this solves the why, we have a new problem: Translations
And these texts are quickly written in a way a user can't use:
What the hell is a "delta"? -> debian-l10n-english to the rescue!?
Its really up to the debdelta package to tell the user what it does as in
this case it seems to be a plugin, so this should be an "Enhances" even if
from a technical point the "glue" to use debdelta is in the package the
enhances would point to.
Of course, this doesn't work if wget is used instead of debdelta in the
example as wget is used by a lot of stuff, but always for the same task:
So annotating all dependencies on wget with the tag use:downloading just
feels wrong. And the package wget is already tagged with use:downloading,
we just don't make proper use of this so far.
So in summary, I see a need for it, and I would like to reserve the syntax
we will use for build-profiles in build-dependencies also in "normal"
dependencies as use-profiles (as Johannes has already pointed to), but we
should really use the current information we already have much more and
take the new syntax we could use in ~2 releases as an override/selector
(e.g. iceweasel has 3 uses, so we could select which one is meant).
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fComDVFrVKUTmCUNDDGaMQpmxmmrSZgfGoFy=qmkvk...@mail.gmail.com
Re: New version of libselinux makes libpcre3 pseudo-essential
On Wed, May 8, 2013 at 8:09 PM, Marc Haber wrote: > On Wed, 8 May 2013 11:56:15 +0200, Bastian Blank > wrote: >>Please re-read the policy, especially 2.5: >>| Packages must not depend on packages with lower priority values >>| (excluding build-time dependencies). > > IIRC that policy paragraph is from the times where our CD build > software didn't follow dependencies when choosing packages for images. > Afaik, they have been following dependencies for a decade now, so this > policy paragraph could be removed. Please don't. Various tools might depend on it. APT will e.g. refuse to consider "required" packages from being autoremoved and while it is fixed since squeeze, it used to boggle on violations (#583517). It's also using the priorities in its scoring calculations to decide which packages are more important to keep working (granted, dependencies will influence it too, but every point might count). Lifting this requirement makes priorities useless in the end as an "optional" package which is a dependency of an "important" package is not "optional". It must be dealt with by software as well as people as if it is important, so lets just mark it that way – or drop priorities completely, but not some wishy-washy middle ground. Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fc0jo4hhemeg_r9wghaqrpi7gungcuun3jbklowptg...@mail.gmail.com
