new package format

[Eugene Gorodinsky]

Hi all
I've read the debian news announcement today
(http://www.debian.org/News/2009/20090730). What got me very
interested was the part about a new package format (in my oppinion
this area can be vastly improved, and I'm interested in contributing).
Searching the list archives I was unable to find any discussion
relating to that, except for the multi-arch spec and a discussion that
took place way back in 1999. Is there anything I might have missed?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Sebastian Krause]

Eugene Gorodinsky  wrote:
> I've read the debian news announcement today
> (http://www.debian.org/News/2009/20090730). What got me very
> interested was the part about a new package format (in my oppinion
> this area can be vastly improved, and I'm interested in contributing).
> Searching the list archives I was unable to find any discussion
> relating to that, except for the multi-arch spec and a discussion that
> took place way back in 1999. Is there anything I might have missed?

http://wiki.debian.org/Projects/DebSrc3.0


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Giacomo A. Catenazzi]

Eugene Gorodinsky wrote:

Hi all
I've read the debian news announcement today
(http://www.debian.org/News/2009/20090730). What got me very
interested was the part about a new package format


There are two changes: one about the source package format
(a true format change) and about binary package format
(this is only a "formal" change about supported compressions
algorithms, not real changes on functionality).

Anyway these two format are already defined by long time
(we need to have support of new format some releases
before actual use, in order to provide smooth upgrades)

So IMHO this is not the right period to discuss about a
new format: we still have to use a "old new format".



(in my oppinion
this area can be vastly improved, and I'm interested in contributing).


What are the problems of actual format?


Searching the list archives I was unable to find any discussion
relating to that, except for the multi-arch spec and a discussion that
took place way back in 1999. Is there anything I might have missed?


Check the changelogs of dpkg to find when people discussed it.

Anyway there were not real change since a lot of time. In last
10 years IIRC there was some support to "tar" extensions and
compressing algorithm.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Eugene Gorodinsky]

2009/7/31 Giacomo A. Catenazzi :
> Eugene Gorodinsky wrote:
>>
>> Hi all
>> I've read the debian news announcement today
>> (http://www.debian.org/News/2009/20090730). What got me very
>> interested was the part about a new package format
>
> There are two changes: one about the source package format
> (a true format change) and about binary package format
> (this is only a "formal" change about supported compressions
> algorithms, not real changes on functionality).
>
> Anyway these two format are already defined by long time
> (we need to have support of new format some releases
> before actual use, in order to provide smooth upgrades)
>
> So IMHO this is not the right period to discuss about a
> new format: we still have to use a "old new format".
>
>
>> (in my oppinion
>> this area can be vastly improved, and I'm interested in contributing).
>
> What are the problems of actual format?
>
For one the dependencies are specified as actual packages, rather than
the actual files themselves. Thus, if a user has installed some
library by `make install`, s/he cannot install a program packaged as a
deb, that relies on the library without some pain.

On windows a program may contain some optional components, which you
can choose at install time. This approach (I mean having some main
package and some required and some optional subpackages inside it) is
quite user-friendly. Neither dpkg nor apt have this functionality in
them, and I do not think it's possible to implement it without
changing the package format.

I also think some abstraction from the actual filesystem is a good
idea. For example currently the only way to install a lib in a
directory other than the one it was intended for is by using a hack
that would look at the directory of a file and move it somewhere. It
seems that with the current situation where you want to use
/lib/i386-linux-gnu tuples instead of the approach used before, would
be less painful if the current package format had some abstraction
from the filesystem. Since the programs don't usually care where the
library is, as long as it is in the LDD_LIBRARY_PATH.

The translations packages could be specifically marked as such, so
that a user could easily check if her package has translations for her
native language. The same applies for documentation, probably, which
could be made into an optional subpackage.

Currently debian policy is to have a .desktop file for each GUI
program. What would be better, IMHO, is having some sort of
abstraction, so that the package manager itself would create a
.desktop file entry, given an icon and some information about the
package.

Since programs usually store their settings in the user's home
directory, that aren't deleted when the program is uninstalled the
user's home directory becomes a mess. I'm not sure if it's possible to
change some functionality within dpkg without changing the format
itself.

>> Searching the list archives I was unable to find any discussion
>> relating to that, except for the multi-arch spec and a discussion that
>> took place way back in 1999. Is there anything I might have missed?
>
> Check the changelogs of dpkg to find when people discussed it.
>
> Anyway there were not real change since a lot of time. In last
> 10 years IIRC there was some support to "tar" extensions and
> compressing algorithm.
>
> ciao
>        cate
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Sebastian Krause]

Eugene Gorodinsky  wrote:
> On windows a program may contain some optional components, which you
> can choose at install time. This approach (I mean having some main
> package and some required and some optional subpackages inside it) is
> quite user-friendly. Neither dpkg nor apt have this functionality in
> them, and I do not think it's possible to implement it without
> changing the package format.

Recommends and Suggests do exactly that.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[brian m. carlson]

On Fri, Jul 31, 2009 at 03:32:43PM +0300, Eugene Gorodinsky wrote:

> On windows a program may contain some optional components, which you
> can choose at install time. This approach (I mean having some main
> package and some required and some optional subpackages inside it) is
> quite user-friendly. Neither dpkg nor apt have this functionality in
> them, and I do not think it's possible to implement it without
> changing the package format.

We do this by having multiple packages.  For example, OpenOffice has
different components: not only are there the different programs (writer,
math, etc.) but there are different language packs.  These are optional
components; for example, since I do not speak Danish, I would not want
to install the Danish language pack.  It would be useless to me.

I agree that this functionality is not built into one single package,
but I think that Debian's way is superior, since it means that I needn't
download data that I don't need, and it is extremely easy to determine
what components I have installed.  It also makes it easy to reuse those
same components in other, unrelated packages.  If groff can make use of
LaTeX hyphenation patterns, then groff can declare a recommends on those
packages without having to necessarily install LaTeX.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: new package format

[Giacomo A. Catenazzi]

Eugene Gorodinsky wrote:

2009/7/31 Giacomo A. Catenazzi :

Eugene Gorodinsky wrote:

(in my oppinion
this area can be vastly improved, and I'm interested in contributing).

What are the problems of actual format?


For one the dependencies are specified as actual packages, rather than
the actual files themselves. Thus, if a user has installed some
library by `make install`, s/he cannot install a program packaged as a
deb, that relies on the library without some pain.


It is difficult to track the version of a file, and it is very difficult to
know if a version is compatible with our packages. There are a lot of
other important things to check (ABI), not only the version.
In general it is impossible to do right dependencies to external/local
installed packages.



On windows a program may contain some optional components, which you
can choose at install time. This approach (I mean having some main
package and some required and some optional subpackages inside it) is
quite user-friendly. Neither dpkg nor apt have this functionality in
them, and I do not think it's possible to implement it without
changing the package format.


In debian is done by different packages (within the same source).
Usually these related packages are listed in "Suggests" or/and
have a common prefix in package name.
User interface problems are outside package format.



I also think some abstraction from the actual filesystem is a good
idea. For example currently the only way to install a lib in a
directory other than the one it was intended for is by using a hack
that would look at the directory of a file and move it somewhere. It
seems that with the current situation where you want to use
/lib/i386-linux-gnu tuples instead of the approach used before, would
be less painful if the current package format had some abstraction
from the filesystem. Since the programs don't usually care where the
library is, as long as it is in the LDD_LIBRARY_PATH.


Not sure I understand, and security implication should be handled
with care.

Anyway RH has support to install packages in own homes. This kind of
abstraction could be nice to have.



The translations packages could be specifically marked as such, so
that a user could easily check if her package has translations for her
native language. The same applies for documentation, probably, which
could be made into an optional subpackage.


I think this is not a problem of package format, but of user
interface.



Currently debian policy is to have a .desktop file for each GUI
program. What would be better, IMHO, is having some sort of
abstraction, so that the package manager itself would create a
.desktop file entry, given an icon and some information about the
package.


This is outside package format. Anyway it is being standardized.



Since programs usually store their settings in the user's home
directory, that aren't deleted when the program is uninstalled the
user's home directory becomes a mess. I'm not sure if it's possible to
change some functionality within dpkg without changing the format
itself.


This was already discussed, and it is impossible to solve.
Package managers must not touch homes. Check archives about
a lot discussions about this.


IMHO you are trying to solve problems on the wrong level.
Package format is a low level format. A lot of stuff can
be done with actual package format, but with improvement
of user interface or/and with triggers and postinst
stuffs.

Actual system is not perfect. You can help, but it is not
so easy to improve such things in a sane way without
causing troubles with existing users.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Am Fr den 31. Jul 2009 um 13:32 schrieb Eugene Gorodinsky:
> Since programs usually store their settings in the user's home
> directory, that aren't deleted when the program is uninstalled the
> user's home directory becomes a mess. I'm not sure if it's possible to
> change some functionality within dpkg without changing the format
> itself.

I don't want to go into the other arguments (yet). But this argument is
very interesting.

On one hand it ends in privacy problems if a user wants to keep his
configuration stuff of one application (especially when he has a shared
$HOME).

On the other hand there could be a tool to cleanup such stuff. But this
might be not connected with the real packages then better a own
application with a data base of know applications.

Regards
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSnLsdZ+OKpjRpO3lAQqPtQgApHrpTQD9Apxy3JcHifL+P525aWQ1B/qI
gipsOo7Iw4btUhSkPoRkh0fPHzooEn3zIN7Kku4dMvvrQ5OLnIn+I/ZG2bEsGaQE
S2zDdETmNgoQpFPVz4SaYcUb/oFbRTbVdPGlPaiONCrDKZZGB4I7Lo/HTKopJYv4
PN/u+pb0VCe7cKa150TScPKDzhCimZlxN9kznvPrVqce/fl18caG8VkkhtATQDWG
Z7AUmSh8DktuuaQH4fjQJvFSkK5Flf0JSlqRfPYUCSeKhyG0d637TOaftCkYxygn
KIqeQR/4h7+6s9UpHgyj0txsU0TQWyzQlaiEDD7/9ftjk4esbPWLaQ==
=UNwx
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Adrian Perez]

Hello.

This may not be relevant in here, but I felt the need to ask.
There's any plan of supporting another format - without breaking
compatibility, I mean supporting - besides the RFC one?
I think YAML would be a good one.
IMHO there is stuff that could be somehow automated, then reviewed, but
not done entirely by hand, sort of blueprint.
I recall, that might not be relevant, but answers welcome.


signature.asc
Description: This is a digitally signed message part

Re: new package format

[Eugene Gorodinsky]

2009/7/31 Giacomo A. Catenazzi :
> Eugene Gorodinsky wrote:
>>
>> 2009/7/31 Giacomo A. Catenazzi :
>>>
>>> Eugene Gorodinsky wrote:

 (in my oppinion
 this area can be vastly improved, and I'm interested in contributing).
>>>
>>> What are the problems of actual format?
>>>
>> For one the dependencies are specified as actual packages, rather than
>> the actual files themselves. Thus, if a user has installed some
>> library by `make install`, s/he cannot install a program packaged as a
>> deb, that relies on the library without some pain.
>
> It is difficult to track the version of a file, and it is very difficult to
> know if a version is compatible with our packages. There are a lot of
> other important things to check (ABI), not only the version.
> In general it is impossible to do right dependencies to external/local
> installed packages.
>
>
>> On windows a program may contain some optional components, which you
>> can choose at install time. This approach (I mean having some main
>> package and some required and some optional subpackages inside it) is
>> quite user-friendly. Neither dpkg nor apt have this functionality in
>> them, and I do not think it's possible to implement it without
>> changing the package format.
>
> In debian is done by different packages (within the same source).
> Usually these related packages are listed in "Suggests" or/and
> have a common prefix in package name.
> User interface problems are outside package format.
>
>
>> I also think some abstraction from the actual filesystem is a good
>> idea. For example currently the only way to install a lib in a
>> directory other than the one it was intended for is by using a hack
>> that would look at the directory of a file and move it somewhere. It
>> seems that with the current situation where you want to use
>> /lib/i386-linux-gnu tuples instead of the approach used before, would
>> be less painful if the current package format had some abstraction
>> from the filesystem. Since the programs don't usually care where the
>> library is, as long as it is in the LDD_LIBRARY_PATH.
>
> Not sure I understand, and security implication should be handled
> with care.
>
> Anyway RH has support to install packages in own homes. This kind of
> abstraction could be nice to have.
>
That's sort of what I had in mind, except on a larger scale where a
package is simply marked as being a shared library and perhaps given
some tag, e.g. "base". The package manager would then install it into
/lib or wherever it deems necessary.

>
>> The translations packages could be specifically marked as such, so
>> that a user could easily check if her package has translations for her
>> native language. The same applies for documentation, probably, which
>> could be made into an optional subpackage.
>
> I think this is not a problem of package format, but of user
> interface.
>
What I meant was to have some certain predefined types of packages, so
that it was easy for the package manager to tell which packages are
translations, which are libraries, which are documentation etc., and
also easy to tell which translation/documentation packages belong to a
particular piece of software.


>
>> Since programs usually store their settings in the user's home
>> directory, that aren't deleted when the program is uninstalled the
>> user's home directory becomes a mess. I'm not sure if it's possible to
>> change some functionality within dpkg without changing the format
>> itself.
>
> This was already discussed, and it is impossible to solve.
> Package managers must not touch homes. Check archives about
> a lot discussions about this.
>
Any pointers on what to search for? My search proved unsuccessful (again)
Anyway, wouldn't specifying which files need to be deleted from the
user's home directory solve the issue?

>
> IMHO you are trying to solve problems on the wrong level.
> Package format is a low level format. A lot of stuff can
> be done with actual package format, but with improvement
> of user interface or/and with triggers and postinst
> stuffs.
>
I hope I am. Would make things much easier :)

> Actual system is not perfect. You can help, but it is not
> so easy to improve such things in a sane way without
> causing troubles with existing users.
>
I'll look into the current format more, since I guess I might have
missed a few things.

> ciao
>        cate
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Goswin von Brederlow]

Klaus Ethgen  writes:

> Hi,
>
> Am Fr den 31. Jul 2009 um 13:32 schrieb Eugene Gorodinsky:
>> Since programs usually store their settings in the user's home
>> directory, that aren't deleted when the program is uninstalled the
>> user's home directory becomes a mess. I'm not sure if it's possible to
>> change some functionality within dpkg without changing the format
>> itself.
>
> I don't want to go into the other arguments (yet). But this argument is
> very interesting.
>
> On one hand it ends in privacy problems if a user wants to keep his
> configuration stuff of one application (especially when he has a shared
> $HOME).
>
> On the other hand there could be a tool to cleanup such stuff. But this
> might be not connected with the real packages then better a own
> application with a data base of know applications.
>
> Regards
>Klaus

End becomes a real mess when home is shared between systems or users
have their own version of things in ~/bin/.

The right thing to do is to make software not create ~/.whatever
unless there is actualy something changed in there. There really is no
need to duplicate the system wide defaults or programs default unless
the user changes them.

So two things: Leave conffiles on removals and don't create them in
the first place.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Russ Allbery]

Adrian Perez  writes:

> This may not be relevant in here, but I felt the need to ask.
> There's any plan of supporting another format - without breaking
> compatibility, I mean supporting - besides the RFC one?

There isn't any plan that I'm aware of.

> I think YAML would be a good one.

What would be the gain?  I can think of one point at least, namely more
standard libraries for parsing the format, but parsing the current format
isn't particularly difficult and that doesn't seem to be worth the work to
support more formats.  Are there other advantages?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Charles Plessy]

Le Fri, Jul 31, 2009 at 03:32:43PM +0300, Eugene Gorodinsky a écrit :
> 
> Currently debian policy is to have a .desktop file for each GUI
> program. What would be better, IMHO, is having some sort of
> abstraction, so that the package manager itself would create a
> .desktop file entry, given an icon and some information about the
> package.

Hi Eugene,

Debian policy is to have a Debian menu entry for each GUI program.  This is not
to be confused with the FreeDesktop menu that is used by GNOME, KDE, Xfce, …

The Debian menu is sometimes made available inside the FreeDesktop menu as a
‘Debian’ category, and therefore each GUI program that has a Debian menu entry
also has a .desktop file on systems that can make use of it. But this one is
autogenerated and is not in the source package.

Many packages do however distribute a .desktop file that contain a fully
FreeDesktop-compliant menu entry, but this is up to the maintainer to write
such a file or install the one provided upstream.

There is an ongoing slow-pace discussion about factorising the information
between the two menu systems, and possibly use the same file format
(FreeDesktop), while preserving the essence of each menus. The Debian menu is
in particular needed in desktop environments – often lightweight – that are not
compliant to the FreeDesktop standards.

http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

Menu entries usually do not indicate the path to the program or the icon, and
finding them is delegated to the menu system itself, be it in Debian or
FreeDesktop standard. I think that what you propose is more their task than the
one of the packaging system.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Tollef Fog Heen]

]] Eugene Gorodinsky 

| I also think some abstraction from the actual filesystem is a good
| idea. For example currently the only way to install a lib in a
| directory other than the one it was intended for is by using a hack
| that would look at the directory of a file and move it somewhere. It
| seems that with the current situation where you want to use
| /lib/i386-linux-gnu tuples instead of the approach used before, would
| be less painful if the current package format had some abstraction
| from the filesystem. Since the programs don't usually care where the
| library is, as long as it is in the LDD_LIBRARY_PATH.

Except that this doesn't work particularly well.  Libraries embed
paths, and detecting when they do is painful.

[...]

| Currently debian policy is to have a .desktop file for each GUI
| program. What would be better, IMHO, is having some sort of
| abstraction, so that the package manager itself would create a
| .desktop file entry, given an icon and some information about the
| package.

like, the path, the description, translated into multiple languages and
so on?  This is just .desktop files reinvented.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: new package format

[Eugene Gorodinsky]

2009/8/1 Tollef Fog Heen :
> ]] Eugene Gorodinsky
>
> | I also think some abstraction from the actual filesystem is a good
> | idea. For example currently the only way to install a lib in a
> | directory other than the one it was intended for is by using a hack
> | that would look at the directory of a file and move it somewhere. It
> | seems that with the current situation where you want to use
> | /lib/i386-linux-gnu tuples instead of the approach used before, would
> | be less painful if the current package format had some abstraction
> | from the filesystem. Since the programs don't usually care where the
> | library is, as long as it is in the LDD_LIBRARY_PATH.
>
> Except that this doesn't work particularly well.  Libraries embed
> paths, and detecting when they do is painful.
>
Haven't thought of that, thanks for the input.

> [...]
>
> | Currently debian policy is to have a .desktop file for each GUI
> | program. What would be better, IMHO, is having some sort of
> | abstraction, so that the package manager itself would create a
> | .desktop file entry, given an icon and some information about the
> | package.
>
> like, the path, the description, translated into multiple languages and
> so on?  This is just .desktop files reinvented.
>
Not quite. This separates the actual files the program uses and needs
from the files that are needed by the user. It's up to the package
manager to decide what to do with the information provided to it (e.g.
it could create a desktop icon, a menu icon, add an icon to a dockbar
or run the program once it is installed etc.). Granted, you can scan
the package and check if it has a .desktop file and read it if the
file exists, however this is a bit hackish.

> --
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Ae and new package format.

[Dale Scheetz]

After getting pgp up and running, I only had to try dpkg-buildpackage
about 4 times before I got it right. (That's actually very easy) At each
step of the way the errors were informative enough to get me down the
road. 
I got several errors about the failure of getpwd to return a path.
Diff -u appears to choke on files that do not end in proper newlines. For
the changelog this required the addition of a "bare" newline at the end of
the file.
I also had to move my pgp keys into /root/.pgp so I could sign the proper
files. I think, from what I have seen in the documentation that I could
have built this as dwarf (rather than root) but the setup for "getting
root privilage" wasn't clear, so copying the keys was the "quick fix".

So far, I really like the new source format. Thank you Ian for all the
fine work and documentation effort! I really like the way that
dpkg-buildpackage (or more likely dpkg-source) packs up the original tree
in a tar.gz file and then gets rid of the tree. Nice space saving,
specialy since it uses the tar.gz file whenever it needs to reference
anything in the original source.
I am still a little foggy about how pre-depends are handled (or if they
are even necessary any longer) and the issues of depends in general, but I
have more complex packages that will surely teach me these points ;-)

As soon as master gets back within my reach, I will upload the new ae
package to incoming. Although there is some discussion about announcing
new Debian packages, it isn't clear if our announcement policy has changed
in general. Do I need to announce the upload to master anywhere besides
here? Do I even need to do that here? It might me nicer if the
announcements were generated when the package was moved from Incoming to
it's host tree. That way they would be less pre-mature.

Thanks,

Dwarf

  --

aka   Dale Scheetz   Phone:   1 (904) 877-0257
  Flexible Software  Fax: NONE 
  Black Creek Critters   e-mail:  [EMAIL PROTECTED]

 If you don't see what you want, just ask --

Re: Ae and new package format.

[Bruce Perens]

From: Dale Scheetz <[EMAIL PROTECTED]>
> I got several errors about the failure of getpwd to return a path.

One of the directories above the current directory is not readable?

Bruce

Re: Ae and new package format.

[Dale Scheetz]

On Wed, 4 Sep 1996, Bruce Perens wrote:

> From: Dale Scheetz <[EMAIL PROTECTED]>
> > I got several errors about the failure of getpwd to return a path.
> 
> One of the directories above the current directory is not readable?
> 
By root? Pwd works ok. I'll keep an eye out. Next time I see these errors,
I'll capture a log and investigate it more closely.

Thanks,

Dwarf

  --

aka   Dale Scheetz   Phone:   1 (904) 877-0257
  Flexible Software  Fax: NONE 
  Black Creek Critters   e-mail:  [EMAIL PROTECTED]

 If you don't see what you want, just ask --