Re: Please test master branch and update-alternatives in particular
On Sun, 22 Feb 2009, Neil Williams wrote: > Something that may not have come up before, I'm looking for a way for > update-alternatives to fail gracefully if things like man pages simply > don't exist on the filesystem. (Emdebian doesn't have manpages but > the Grip flavour does have other targets of alternatives - Crush > drops alternatives completely.) You should read the set of changes first. This should be taken care of with this change: - install slave link only if the corresponding slave file is available. Closes: #143701 Guillem expressed a concern about this change on IRC and I tried to explain why I believe it's the right behaviour: buxy: I don't think ignoring non existing files for slave alternatives is a good idea they are not only used for man pages I had some comments in 505207 braindmg: I've read those comments but: 1/ you can't store whether the slave is optional in the db without breaking backwards compatibily and you want to be able to repair the alternative not only in --install 2/ the ratio of non-optional slave compared to those who are is rather big in practice 3/ the old update-alternatives did not fail when the target file was missing, it simply created dangling symlinks (the problem only arised when the alternative link had to be created in a non-existing dir) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please test master branch and update-alternatives in particular
On Sun, 22 Feb 2009 23:24:15 +0100 Raphael Hertzog wrote: > Hello, > > as some might have noticed I largely rewrote update-alternatives, > corrected bugs and implemented most features requested in the BTS. Hmm, maybe I left it too late to put my own request into the BTS for update-alternatives. :-( > With any change of this importance, and despite the (relatively extensive) > test-suite which covers most important actions, I expect that we'll find > small problems, in particular in the user interface or in messages > displayed. > > Please compile and run the dpkg in the master branch and report any > problem you might have with update-alternatives. TIA. Something that may not have come up before, I'm looking for a way for update-alternatives to fail gracefully if things like man pages simply don't exist on the filesystem. (Emdebian doesn't have manpages but the Grip flavour does have other targets of alternatives - Crush drops alternatives completely.) Currently, I'm using a config package to replace the current update-alternatives with a minor change that brute forces things to make update-alternatives exit with zero instead of 2 in the quit subfunction. Yes, I know, it's a hack but I needed to get it fixed to get Grip working and planned on getting a sane implementation in a few weeks time and bringing it to dpkg at that time. Just from the bare outline, is there a good way of implementing a fix for this? I can create a file in /etc/ that update-alternatives notices in order to change behaviour, that seemed like the best initial approach. (Doesn't have to be in /etc/ actually.) Does update-alternatives need to fail noisily / die if the target of an alternative does not exist? (thereby breaking the install). Has this been looked at before? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpNdiHAvdKNV.pgp Description: PGP signature
Please test master branch and update-alternatives in particular
Hello, as some might have noticed I largely rewrote update-alternatives, corrected bugs and implemented most features requested in the BTS. With any change of this importance, and despite the (relatively extensive) test-suite which covers most important actions, I expect that we'll find small problems, in particular in the user interface or in messages displayed. Please compile and run the dpkg in the master branch and report any problem you might have with update-alternatives. TIA. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Merging dpkg-cross into the dpkg source
Hello, > gcc is still lacking some patches to properly support building using > the multiarch dirs, Aurélien Jarno said he would be preparing some > patches for which Matthias Klose agreed to include (at least agreed with > the idea behind the patches). > > Once we have a working toolchain we can start drafting the details for > the implementation in the packaging level, and we'll be able to test > stuff easily. Although, there's already some previous implementation > work from at least Hugo Mills and Tollef Fog Heen that I'm aware of. I would like to refer to some work[1] regarding multiarch goswin has done. As other resources, multiarch has a debian wiki page[2] but it seems that work towards that direction is much stalled AFAIK. Cheers -- Héctor Orón [1] http://alioth.debian.org/tracker/index.php?func=detail&aid=310911&group_id=30462&atid=411196 [2] http://wiki.debian.org/multiarch/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is 1-0 equal to 1 as a version?
Florian Weimer writes:
> $ python -c 'import apt_pkg; apt_pkg.init(); print
> apt_pkg.VersionCompare("1", "1-0")'
> -1
> $ dpkg --compare-versions '1' = '1-0'; echo $?
> 0
>
> I think dpkg is right because policy says:
>
> | The absence of a is equivalent to a
> | of `0'.
Policy was changed to match dpkg in April of 2007:
* Policy: better document version ranking and empty Debian revisions
Wording: Russ Allbery
Seconded: Raphaël Hertzog
Seconded: Manoj Srivastava
Seconded: Guillem Jover
Closes: #186700, #458910
> So this looks like a bug in APT. But I think that in practice, the
> APT algorithm is the dominant one, so it might make sense to update
> policy and dpkg instead.
Debian revisions of -0 are quite rare in practice, which is probably why
no one has noticed the discrepancy. We had a discussion of this in:
http://bugs.debian.org/458910
although I don't think anyone realized at the time that apt didn't do the
same thing as dpkg. My feeling is that dpkg should probably win here, but
I guess I don't feel strongly about it.
--
Russ Allbery (r...@debian.org)
Is 1-0 equal to 1 as a version?
$ python -c 'import apt_pkg; apt_pkg.init(); print apt_pkg.VersionCompare("1",
"1-0")'
-1
$ dpkg --compare-versions '1' = '1-0'; echo $?
0
I think dpkg is right because policy says:
| The absence of a is equivalent to a
| of `0'.
So this looks like a bug in APT. But I think that in practice, the
APT algorithm is the dominant one, so it might make sense to update
policy and dpkg instead.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Merging dpkg-cross into the dpkg source
On Fri, 20 Feb 2009 16:08:45 +1030 Ron wrote: > On Thu, Feb 19, 2009 at 10:24:34AM +, Neil Williams wrote: > > On Thu, 19 Feb 2009 08:47:47 +0200 > > Guillem Jover wrote: > > > > > > 3. Any renaming issues or other changes required in the current package? > > > > > > There's the arch name divergences, from the IRC logs, I think most > > > should just be removed and the ones from dpkg-architecture used > > > instead. If those need fixing then we should check for each specific > > > case. > > > > The only remaining values are: > > > > armeb: armeb-linux-gnueabi > > hurd-i386: i386-gnu#XXX This differs from dpkg-architecture > > s390x: 's390-linux-gnu' #XXX This differs from dpkg-architecture > > openbsd-i386: 'i386-openbsd' #XXX This differs from dpkg-architecture > > freebsd-i386: 'i386-freebsd' #XXX This differs from dpkg-architecture > > darwin-i386: 'i386-darwin', #XXX This differs from dpkg-architecture > > win32-i386: 'i386-cygwin' > > > > Compare in each case with the output of: > > $ dpkg-architecture -a$key -qDEB_HOST_GNU_TYPE 2>/dev/null > > > > The main effect is to allow i386 in the GNU type where dpkg insists on > > changing it to i486. > > > > The mechanism itself was intended to support uClibc architectures - > > Simon? > > The other issue related to this was some mechanism to permit local > definitions to be maintained in ostable and triplettable. /etc/dpkg-cross/archtable.d/ could be extended for that purpose - it's a much better idea than the legacy method of hardcoding such variants into dpkg-cross itself. It was originally designed for this situation, so if it isn't suitable, it needs to be fixed. See #447427 > The rationale is, things like arm and uclibc have many possible variants, > and we cannot possibly provide them all by default. archtable.d/ was meant for this support - although the name does tend to indicate only one side of the table but that can be changed. The questions are: 1. Do you need to alter ostable, archtable and tripletable or can we arrange a method to host all three in one file/directory? Combining the tables requires an element of rigour to the definitions and should prevent overlaps or omissions. 2. Do you need dpkg to support this directly or will support via other tools be sufficient? (i.e. as now with archtable and dpkg-cross). If so, which tools? (bearing in mind that dpkg-cross itself will disappear). Maybe what we shall end up doing is migrating the package conversion routines from /usr/bin/dpkg-cross into dpkg|dpkg-dev using multi-arch support and implementing the architecture-support configuration of dpkg-cross as a configuration package that handles the static data like cross-config. $arch, archtable.d/ and the rest in /etc/. The only issue for me is about the status of multi-arch in Debian - where are we at? > While we may provide > one or more of them for general use, specialised devices are each going > to want to enable or disable different (sometimes incompatible) features. To do so, you may well need to also modify the cross-config.cache values as these provide the results of macros run by autoconf based on a standard Debian system. If uClibc or any other variant changes the behaviour of functions compared to standard glibc and standard Debian, the variant would also need to take account of these changes. > Since the majority of the > 2000 arm machine types now registered with the > linux kernel are in some way or another specialised, this is very > desirable from the point of view of manufacturers trying to get the best > performance from their devices using an OS built from Debian sources, > and cross tools on a Debian host workstation to build it all. Then what we need is a test suite for these systems whereby we get the results of the ./configure tests performed by each package currently supported by /etc/dpkg-cross/cross-config.cache or putting files into /etc/dpkg-cross/cross-config.d/ in a native build and then reporting back on any changes in the cached values. There is a prototype script to do that kind of thing in emdebian-tools already, emcache. Patches to modify it for such a test suite would be welcome. ;-) > Delineating them by triplets works well as the toolchains and autoconf > all support this cleanly without any extra hackery required. > > I've been using a specialised arm/uclibc toolchain like this with our > products since about the middle of 2007 and it's been working really > nicely. The only thing I need to keep tweaking is to add: > > ostable: > uclibc-linux linux-uclibclinux[^-]*-uclibc > > triplettable: > uclibc-linux-uclibc- > > ... every time I update dpkg and they get overwritten again. OK, so which executables and which routines need to call these values - would support inside dpkg-cross be sufficient or are you seeking for dpkg to support /etc/dpkg/arch.d/ instead? Most of the support you need does exist but it sounds like it needs to be optimised. There is no
