Re: couple of nits/warnings

1999-10-06 Thread Dale Scheetz
On Tue, 5 Oct 1999, Bdale Garbee wrote:

> In article <[EMAIL PROTECTED]> you wrote:
> 
> > tar -zxf control.tar.gz control ./control
> 
> You can also use 
> 
>   tar -zxf control.tar.gz *control
> 
> which does not produce an error, and extracts either one.  This is the fix I
> supplied for lintian when the tar upstream changed the way pathname whacking
> happens in tar... which our tools depended on.  Given that we know what's in
> a control.tar.gz, the wildcard is not problematic.



Yep, in this special case that is equivalent. Thanks! I'm very happy to
get rid of two error messages per package ;-)

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:  [EMAIL PROTECTED] Tallahassee, FL  32308

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



Re: couple of nits/warnings

1999-10-06 Thread Bdale Garbee
In article <[EMAIL PROTECTED]> you wrote:

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

You can also use 

tar -zxf control.tar.gz *control

which does not produce an error, and extracts either one.  This is the fix I
supplied for lintian when the tar upstream changed the way pathname whacking
happens in tar... which our tools depended on.  Given that we know what's in
a control.tar.gz, the wildcard is not problematic.

Bdale



Re: couple of nits/warnings

1999-10-05 Thread Dale Scheetz
On Tue, 5 Oct 1999, Dale Scheetz wrote:

> 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)?

I just figured out what this is all about. It turns out that the directory
I was buiding them in had no group write premission, hense dpkg rightfully
left it off. Once I changed the directory to have write permission for
groups everything is as expected.

Waiting is,

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

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

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



couple of nits/warnings

1999-10-05 Thread Dale Scheetz
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:  [EMAIL PROTECTED] Tallahassee, FL  32308

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