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

couple of nits/warnings



As you may know, I have been working on a script to build selected subsets
of the distribution from source, to be used for constructing single CD
releases of ED (Essential Debian).

With the correction of my faulty grep|awk filter I have been able to build
more complex lists of packages (and can even build gcc on a slink system)
when I started seeing a previously unseen failure in my script. 

The line that extracts the control file from the archives with a tar
command was failing, telling me that "control" was not in the archives.

A bit of exprimentation showed that the tar in slink can only find
"control" while the tar in potato can only find "./control". (this from
the same tarball both times)

I resolved the problem with the following line:

tar -zxf control.tar.gz control ./control

which gives an error every time, but extracts the control file every time
as well...such is life ;-)

The man page (I believe in both cases, but I could be wrong) says
that the file name must be given exactly as displayed by the list option.
This would suggest that both versions should accept ./control, as that is
what is printed to the screen when tar lists the contents. So this is a
bug fix in the new release...(I can't really tell from the changelog
without looking up a fair list of bug reports...sorry, I'm lazy ;-)

After all that complex lead-in, my question is quite simple. Since
./control and control are semanticly identical, why is a distinction being
made? I understand that in every other example of this "rule" there is
reason to apply it, to distinguish between files with the same base name
but different paths, but that is not the case here.

The second nit has to do with the way that dpkg assigns permissions to the
package files it creates. I'm not certain why, but I sort of expected the
files to be 664, not the 644 that it produces. If group projects are to be
managable, shouldn't members of the group have write permission on these
files? Is this an "artifact" of the way we do users and groups (giving
the user his own personal group with the same ID)?

This brings up another point relating to inter system compatibility. I did
some very minor beta testing for Caldera (please don't throw tomatoes ;-)
and, as a result, they were very generous in gifting me with a boxed copy
of their new release. I have a laptop with a "finiky" graphics card, and
Caldera was able to make it work in a reasonably high graphics mode,
(something that I haven't been able to get the slink xfree to do at the
same resolution) so I installed it on my "second system" partition, and
immediately ran into problems with the way I wished to configure my
systems (nothing particularly new here ;-)

On machines (like my development box) where I wish to run two or more
version of the distribution, I have several partitions for the root
system, and several partitions for particular (non-unique) components of
the file system. One of these is my home directories. home has its own
partition that gets mounted on /home by each of the various systems I may
be running. (this has been a bit tricky, having to propogate the passwd
files onto new systems from old, but it works pretty well)

So far I have been able to make this work because they have all been
Debian systems. When I added /home to fstab on the Caldera system, I
naturaly lost all access to the system. dwarf on the Debian system has the
uid:gid of 1000:1000, while on the Caldera system dwarf has 500:100.
It felt safe to change the user number on the Caldera system to 1000, but
I didn't want to change the group ID (corresponds to the group "users")
for fear of breaking something on the Caldera system. This allowed me to
login (which I hadn't been able to do before) but I still could not access
my files. While I later realized that I could probably just add dwarf to
the dwarf group (ID 1000) on the Caldera system and it would probably
work, I decided to separate the two systems /usr partitions, putting the
Caldera /usr on the same root as the system, and leaving the Debian
configuration the way it is. Is there a better way to integrate these two
systems than the one I worked out?

Sorry this went so long, I thought I only had two points to make ;-)

Luck,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-


Reply to: