[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using Qt debug libraries without configure and qmake



On Fri, 18 Nov 2011 12:12:33 +0000
Philip Ashmore <contact@philipashmore.com> wrote:

> On 18/11/11 00:07, Neil Williams wrote:
> > On Thu, 17 Nov 2011 20:01:42 +0000
> > Philip Ashmore<contact@philipashmore.com>  wrote:
> >
> >> , presuming they are even installed or the user downloaded (the matching
> >> version of) them.
> > apt-get source - it always gives you the matching version, that's the
> > point.
> presuming you've done apt-get upgrade, which requires elevated(root)
> privileges.

No, if apt-get update ; apt-get upgrade has not been run, you simply
won't get the source package because the reference in the apt-cache
will be to an old version. It is always in lock-step or else it simply
won't be downloaded. If your system is not up to date, you cannot
expect the right sources to be downloaded and any operation on /usr/src
requires sudo or root anyway. 

You cannot get the "wrong version" of the source using apt, with the
exception of pinned packages or backports.

When apt tries to get source, it tries to get the actual version
specified in the previously downloaded Sources file using the URL in
that file. If there is a new version which replaces that one, then the
outdated Sources file will point to a 404. Simple. The Sources file and
the Packages file are updated at the same time, so the binary and the
source are ALWAYS in lockstep. The old source will exist for a little
while in unstable - generally until the slower architectures have all
built the binaries from the new sources - but once it's gone you'd need
to go to snapshot.debian.org to get the matching source for an old
version of the binary. (e.g. if you don't want to upgrade the binary.)

Whatever method is used, the source is unpacked with normal user
privileges and then built under fakeroot to fix up the permissions
inside the binary.

> >> The debugger will only find the file itself if the debugging information
> >> contains an absolute path.
> > Not true. The debugger will look for the path you provide and try to
> > match the files according to the reverse lookup - much the same way as
> > patch.
> so it won't find it itself based on the path provided in the debugging 
> information.

The end of the path will always match, it will match in the same way as
patch works, backwards from the filename, to the upstream directory, to
the dpkg-buildpackage path. The debugger does the matching according to
the symbols exported by the library - so gdb already knows which source
file in which package matches which symbol for which class/struct.

> Sometimes it's far from obvious which package a source file belongs to.
> It would be great if the debugger could tell you.

It doesn't need to tell you, it knows already. All it needs is a path
to the top of the source tree.

If you want to know, try running grep on /var/lib/dpkg/info/*.symbols

> >> Could this be a build option?
> > No, because the actual location varies according to user preference.
> but unless you've built the package from source yourself, the debugging
> information points to just one place - usually the location on the 
> machine that
> built it, not very useful.

Huh? No. The debugging information points to a path and the tail end of
that path is common no matter where it is eventually unpacked. It's the
same filename in the same directory no matter where the package was
built. The symbols tell the debugger which package, the package then
has a unique path to that file. (It has to, every path inside any
individual source package is unique or it can't be packed/unpacked.)

You're thinking of paths from left to right. Think of paths as patch
thinks of a path - right to left.

> > Forget about /usr/src, it isn't useful for the majority of packages.
> > Arbitrary directories specified by the user are the only way to allow
> > developers to debug against a variety of dependencies and in a variety
> > of situations. /usr/src is a privileged path, source does not need a
> > privileged path and is usually far better in a user path.
> >
> > Qt applications or libraries do NOT use /usr/src.
> I'm not a Fedora fan, but that's exactly what they do.

And? Why does that matter to anyone on this list?

> It's a de-facto Debian decision not to standardize on any install path, 
> which is
> bizarre.

Install paths are absolutely standardised according to the FHS but
installation only applies to BINARY packages. Source packages are NOT
installed! Requiring root or sudo just to look at the source of a
package is bizarre.

Look at debcheckout as well or dget.

> Don't forget, some people have accounts on multi-user systems, and filling
> their home directory with package sources is something they simply cannot do
> for space reasons, and even if they could, it duplicates downloads and 
> storage.

So use a directory under /srv or somewhere where the admin has provided
permissions. Many more systems have very, very restricted space
for /usr/ and lots of room in /srv/ or /home/.

That is an argument FOR having source unpacked to wherever the user /
local admin has arranged sufficient space, NOT for a fixed location
which doesn't fit with how the admin needs to setup the machine.

I have accounts on many systems, multi-user and desktop, embedded and
laptop. No matter how the partitions are assigned, I can always
download and unpack the *correct* source without sudo or root and
inspect the actual source code. I just look at the apt-cache to get an
indication of how big the source package will be, choose a download
location with enough space and download it.

No sudo or root required, I can edit files in the source package
without needing to have permission to write in /usr/src/. Building the
modified package also does not need sudo or root - just fakeroot. Built
packages can be unpacked too, dpkg -X is very useful to compare the
results of changes to the source code.

There is no duplication involved. The source is not downloaded until
you ask for it and it is downloaded to where you are, not
into /var/cache. There is no src.deb, there is no other copy. No excess
storage is involved, with the possible exception of the Sources index
file itself which apt retains whether you ever download sources or not.
That's a few Mb and is useful in other apt-cache queries, so it's not
usually a problem.

> With respect, have you had a look at
> http://lists.debian.org/debian-devel/2011/09/msg00517.html
> ?

Yes, and?

Have you even looked at what apt-get source actually does? What do you
think a deb-src repository URL provides? You're assuming that there is
a package_version_src.deb but no such thing exists - a Debian source
package is the unchanged upstream tarball, Debian changes (for a native
package, there are only the Debian 'changes') and a .dsc text file
which gives the checksums for those files, usually wrapped in a GnuPG
signature.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpNa1OeUjcjq.pgp
Description: PGP signature


Reply to: