wget and frames

2007-06-15 Thread Karl Berry
We received this report on webmasters.  Can anyone help Anthony, please?


Hi, 
 
I really like this utility but was having trouble getting 'framed' data
into the output files.
 
It is like when one views the source of the webpage from a browser, this
is what I see in my output file.
 
If I go to view Frame source from the webpage, I see the rest of the
page html.  Is there a way in wget to get this data too without all the
pics/images downloaded?
 
Thanks,
Anthony


wget maintainer?

2007-06-15 Thread Karl Berry
Regrettably, Mauro has had to resign the maintainership of wget.
(Of course, many thanks to him for his work, and at least as many thanks
to Hrvoje for writing it in the first place.)

I have asked a few people individually if they'd like to take over the
package, but none has had time.

Would anyone on this list feel that they have enough time and
inclination to be the new maintainer?  Please write me if you would like
to volunteer.  I'll post in various places if no one comes forward, but
this seemed like the most likely place ...

Thanks,
Karl


Re: gettext and charsets

2003-11-05 Thread Karl Eichwalder
Hrvoje Niksic [EMAIL PROTECTED] writes:

 Perhaps you could try posting to [EMAIL PROTECTED]?  Failing
 that, you might want to try at the address of the Free Translation
 Project and/or the Norwegian national team near you.

[EMAIL PROTECTED] is the preferred list for reporting gettext
bugs.

Implementation issues can be discussed at
[EMAIL PROTECTED] (also read by Bruno Haible).


Re: some wget patches against beta3

2003-10-07 Thread Karl Eichwalder
Hrvoje Niksic [EMAIL PROTECTED] writes:

 As for the Polish translation, translations are normally handled
 through the Translation Project.  The TP robot is currently down, but
 I assume it will be back up soon, and then we'll submit the POT file
 and update the translations /en masse/.

It took a little bit longer than expected but now, the robot is up and
running again.  This morning (CET) I installed b3 for translation.



wget -m imply -np?

2002-12-30 Thread Karl Berry
I wonder if it would make sense for wget -m (--mirror) to imply -np
(--no-parent).  I know that I, at least, have no interest in ever
mirroring anything above the target url(s) -- generally, that leads to
the whole Internet.  An option to explicitly include the parents could
be added.

Just a suggestion.  Thanks for the great software.

[EMAIL PROTECTED]



Re: wget -m imply -np?

2002-12-30 Thread Karl Berry
using -m as a trouble-free no-brainer 
will get you the complete site neatly done with timestamps.

But then you're saying wget -m http://example.org in the first place.

If you say wget -m http://example.org/some/deep/sub/directory, then my
experience is that the last thing one wants is to retrieve the entire
example.org site.  This typically happens to me because it's a directory
listing, and one of the directory entries is for `..'.

Perhaps my usage is atypical.

That is wrong, if I understand you correctly. 
Wget will always stay at the start-host, 

Right, my mistake, I should have said the entire web site.

Thanks,
k




Re: wget 1.8.x bulgarian translation

2002-02-25 Thread Karl Eichwalder

Vesselin Markov [EMAIL PROTECTED] writes:

 I wrote a bulgarian localization of Wget 1.8.1 which 
 i hope you'll accept. I am sending

 wget-1.8.1-BG/po/bg.po
 wget-1.8.1-BG/po/bg.gmo
 wget/share/locale/bg/LC_MESSAGES/wget.mo

Thanks a lot -- but please consider to join the Bulgarian translation
team:

[EMAIL PROTECTED]

At the moment, Yassen Roussev is listed to translate wget but I guess
will appreciate help!

For more info, please visit:

 Free Translation Project:
  http://www.iro.umontreal.ca/contrib/po/HTML/

-- 
Linux frechet 2.4.16-4GB #1 Wed Dec 12 13:42:58 GMT 2001 i686 unknown
  8:52am  up 26 days, 22:14, 13 users,  load average: 1.41, 1.45, 2.33
 work:  [EMAIL PROTECTED]
Karl Eichwalder  home: [EMAIL PROTECTED]



Re: wget 1.8.1: po/el.po update

2002-02-20 Thread Karl Eichwalder

[EMAIL PROTECTED] writes:

 I translated the few remaining messages in the greek po file.
 Here are the diffs.

Please, try to get in contact with the last translator (cf. the Cc:) to
avoid duplicate work.  Thanks a lot!

 Thanks for writing and maintaining such a great tool.

-- 
Linux frechet 2.4.16-4GB #1 Wed Dec 12 13:42:58 GMT 2001 i686 unknown
  3:34pm  up 21 days,  4:55, 13 users,  load average: 0.21, 0.22, 0.20
 work:  [EMAIL PROTECTED]
Karl Eichwalder  home: [EMAIL PROTECTED]



Re: Users and languages, was: Uncoupling translations from source

2001-12-10 Thread Karl Eichwalder

[EMAIL PROTECTED] writes:

 IMO, a bad translation is only useful, if I speak the original 
 language even worse. I'd rather stick to a precise Oxford English than 
 a German Kauderwelsch created by BabelFish (TM).

Just try to translate a middle size program (2-500 message) and you'll
see how un-precise original messages are ;-)  It takes more of my time
to report and discuss inconsistencies than to translate the strings.

 My point is, that _I_ find it easier to use a manual/prog in good 
 English than in bad German. 
 (And, to admit it, I rarely take the time to report translation bugs...)

Additional note, you're not allowed to install programs for your users
in some countries when there's no native language support.

-- 
   Free Translation Project:
Karl Eichwalder http://www.iro.umontreal.ca/contrib/po/HTML/



Re: Uncoupling translations from source

2001-12-09 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 Why is unpacking two tar files instead of one a complication?

At the moment, it just wont work (gettext limitation); nevertheless we
are thinking about the possibility to offer separate translation update
packages.  For it's still essential to ship most recent translations
with every regular package release.

 (And that's provided you want translations in the first place; many
 people don't.)

These people are experts.  They can go directly to the CVS and download
what they need.  Please note, according to my experiences Americans
can stand the translations coming with tar.gz files; only advanced
European users (so called experts) don't like them.

 There are packages that are much more complicated to install than
 that.

The difference is translation are not essential -- thus people will
tend to ignore them if additional efforts are involved.  This might
change in the future but for now that's the truth.

-- 
[EMAIL PROTECTED] (work) / [EMAIL PROTECTED] (home):  |
http://www.suse.de/~ke/  |  ,__o
Free Translation Project:|_-\_,
http://www.iro.umontreal.ca/contrib/po/HTML/ |   (*)/'(*)



Re: Uncoupling translations from source

2001-12-09 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 How can gettext know how many tar files were involved in creating a
 source tree?

Use gettext default files (.am, .in, .m4) you must edit some files
(configure.in or po/LINGUAS) and run automake/autoconf to make the new
languages available.

 Why is it essential?  I can see how it could be useful, but why
 essential?

We (= people involved in the GNU project) think without localization
software is of limited use for the majority of (new) users worldwide.
As documentation is essential so are translations.

 Not necessarily.  Some of them only speak English (see Americans
 from before), but some simply never use translations.

Yes, but I never encoutered an American who felt annoyed by shipping
the translation overhead with regular .tar.gz files.  I'm sure we'll
work out an improved way to distribute translations when more an more
translations will become available -- but for now it's better not to
change the default way to ship them.

 For example, I never use translated programs, although I approve of
 and take part in the translation effort.

I know and I appreciate your POV and your efforts a lot.  All your
proposals are not lost (I've saved them for the future).

 Those people who do want translations will invest the (tiny)
 additional effort and will get them.

I think different :)  At least it will take some time to adjust all
involved pieces: gettext, the robot, every single software package,
translators, maintainers, distributors, etc.  Yes, it's possible to do
-- but it just will take time.

-- 
[EMAIL PROTECTED] (work) / [EMAIL PROTECTED] (home):  |
http://www.suse.de/~ke/  |  ,__o
Free Translation Project:|_-\_,
http://www.iro.umontreal.ca/contrib/po/HTML/ |   (*)/'(*)



Re: English vs Locale

2001-10-29 Thread Karl Eichwalder

Marc St-Jacques [EMAIL PROTECTED] writes:

 When I type 'wget --help', only one tenth of it's output is in my locale's 
 language, in this case, French.
 Now this is a package that came with Mandrake 8.1.  Is it an overall problem 
 with wget or is Mandrake at fault here ?

The official release 1.7 lacks several translations.  By now, it's
complete; cf.:

http://www.iro.umontreal.ca/contrib/po/HTML/domain-wget.html

I'd like to see a new release (1.7.1) with all translations updated.

-- 
Linux frechet 2.4.10-4GB #1 Mon Oct 15 17:27:24 GMT 2001 i686 unknown
 11:14am  up 3 days, 22:55,  6 users,  load average: 0.31, 0.12, 0.08
 work:  [EMAIL PROTECTED]
Karl Eichwalder  home: [EMAIL PROTECTED]



Re: translating into hungarian

2001-10-01 Thread Karl Eichwalder

Szasz Pal [EMAIL PROTECTED] writes:

 I like very mutch the wget porhram, and i obsereved, that it's not yet 
 translated into hungarian.
 I could try to translate it. Are you interested in it?

Great!  Please, consider to join the Translation Project:

http://www.iro.umontreal.ca/contrib/po/HTML/

Special translator info is available as:

http://www.iro.umontreal.ca/contrib/po/HTML/translators.html

 I'm not on the list, so please answer to to the following address:
   [EMAIL PROTECTED]

It's the best to use the Reply-To: header for this purpose.

-- 
Linux frechet 2.4.7-4GB #1 Tue Jul 24 15:07:28 GMT 2001 i686 unknown
  9:59am  up 12 days, 22:14,  7 users,  load average: 0.14, 0.24, 0.12
 work:  [EMAIL PROTECTED]
Karl Eichwalder  home: [EMAIL PROTECTED]



Re: wget and seeding random numbers

2001-06-15 Thread karl

  1 - Use RAND_egd() for reading true random data if such is available (this
  needs to be checked for in the configure script, as RAND_egd() wasn't
  introduced until OpenSSL 0.9.5). This would also benefit from a command
  line option to specify the egd socket. EGD = Entrophy Gathering Daemon.
 
  2 - Use RAND_screen() for windows based systems (gets random data off the
  screen).
 
  3 - Allow a user-specified file for reading random data from with
  RAND_load_file()
 
  4 - Use RAND_file_name() to get what default file (if any) to read random
  data from. (This seems to be done in the lynx code)
 
  5 - *then* you go with the srand(), time and pid seeding stuff.

I'm no expert on openssl, but that looks pretty reasonable, and it's
probably just a couple more calls, so not hard to do?  As long as the
srand()all stuff is there as a final default.

Thanks,
karl



wget and seeding random numbers

2001-06-09 Thread karl

About doing the random number seed for ssl, I dug up what lynx does, and
it looks like it wouldn't be difficult to do something similar in wget.
It appears this code was written by Mark Mentovai [EMAIL PROTECTED],
http://www.moxienet.com/.

Hope it helps.

k

  if(RAND_status()==0) {
char rand_file[256];
time_t t;
pid_t pid;
long l,seed;

t=time(NULL);
pid=getpid();
RAND_file_name((char *)rand_file,256);
CTRACE((tfp,HTTP: Seeding PRNG\n));
if(rand_file!=NULL) {
  /* Seed as much as 1024 bytes from RAND_file_name */
  RAND_load_file(rand_file,1024);
}
/* Seed in time (mod_ssl does this) */
RAND_seed((unsigned char *)t,sizeof(time_t));
/* Seed in pid (mod_ssl does this) */
RAND_seed((unsigned char *)pid,sizeof(pid_t));
/* Initialize system's random number generator */
RAND_bytes((unsigned char *)seed,sizeof(long));
srand48(seed);
while(RAND_status()==0) {
  /* Repeatedly seed the PRNG using the system's random number generator until it 
has been seeded with enough data */
  l=lrand48();
  RAND_seed((unsigned char *)l,sizeof(long));
}
if(rand_file!=NULL) {
  /* Write a rand_file */
  RAND_write_file(rand_file);
}
  }



wget ssl solaris non-randomness

2001-06-08 Thread karl

On Solaris 2.6 and 2.7 (without sufficient patches), openssl doesn't
have enough built-in randomness (see error message below).

It's possible to make the openssl cmdline utility work by setting
RANDFILE to a file containing lots of random data, but wget does not
look at this, as far as I can tell.  openssh has its own fairly
complicated method of running a bunch of commands to seed the random
number generator, which wget also doesn't have (as far as I can tell).
I don't know what lynx does, or other ssl clients.

Anyway, right now wget ssl basically doesn't function on solaris (for me
at least) -- installing the patches on all the dozens of machines at my
sites is not practical and anyway has undesirable side effects, from
what I can tell.  The entropy-daemon approach doesn't appeal either.

Any chance of having it use RANDFILE, at least, or some other way of
telling it where to find some random bytes?

Thanks,
karl

P.S. The error message in question is:
16499:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not 
seeded:md_rand.c:474:You need to read the OpenSSL FAQ, 
http://www.openssl.org/support/faq.html
(And yes, I've read the faq numerous times :)



Re: wget 1.7, linux, -rpath

2001-06-07 Thread karl

Replacing -rpath  with -Wl,rpath  

It has to be -Wl,-rpath, not -Wl,rpath (with the - on rpath too).

All I can say is that after I made that change, the ssl test worked for
me on redhat 7.1 (and so did the ssl functionality :).  I can see how
your other changes might be needed in other cases, though.

On another topic, you might consider upgrading to autoconf 2.50.  It has
a number of nice new features, and at least for me (i.e., Texinfo), the
upgrade was pretty much painless.

Thanks,
karl



wget 1.7, linux, -rpath

2001-06-06 Thread karl

The ssl support is much appreciated in wget 1.7.  But there is a problem
with the configure support that makes it think ssl can't be used, at
least with gcc 2.95.2 on my redhat 6.2 system:

configure:3660: checking for RSA_new in -lcrypto
configure:3679: gcc -o conftest -g -O2  -L/usr/local/openssl/lib -rpath 
/usr/local/openssl/lib  conftest.c -lcrypto   15
gcc: unrecognized option `-rpath'
/usr/local/openssl/lib: file not recognized: Is a directory

This comes from configure:

  decosf* | linux* | irix*) dash_r=-rpath  ;;

-rpath isn't recognized directly by gcc as far as I can tell.
-Wl,-rpath works, though.  I suspect the same would be needed on irix
and decosf but don't know for sure.  -R is recognized directly by gcc on
Solaris, so that part is ok.

Thanks,
karl



Re: wget/src/ftp-ls.c: tiny typo

2001-06-04 Thread Karl Eichwalder

R.I.P. Deaddog [EMAIL PROTECTED] writes:

 For separating translation as another tarball, there's another risk of
 people putting different versions of source and translation together,
 not to mention the additional time needed for packaging.

Yes, this disaster happens for manpages all the time ;-(

 But of course it's up to developers to decide which method costs less
 and which costs more.

Yes.  Using the TP and its defaults isn't mandatory.  Of course it helps
to reduce the organizational(?) overhead if you try to use the TP setup.


Hrvoje Niksic [EMAIL PROTECTED] writes:

 I didn't mean that the translators were lazy or anything like that.
 By too late I meant that `wget.pot' in the current tree is already
 different from `wget-1.7-pre1.pot'!

That's life and translators are used to it.  From pre-release to
pre-release the message will stabilize.  Whenever there are message
string related changes we can install a new .pot file; just announce it
to us ([EMAIL PROTECTED]).  For the moment we still have to
approve such a request; it's on the improvement list to let install
maintainers new versions on their own.

Even if a language file isn't 100% complete a translation is useful.

 Another unfortunate misunderstanding: your asking for the POT file was
 perfectly fine, and I am grateful that you did.

Thanks :)

 The problem on my side is that I don't know what to do with 1.6
 translations,

Hard to tell.  Put them into the wget CVS please.  And if you think it's
useful, release them together with wget 1.6 as wget-1.6.1 (like some
GNOMErs do; KDE people do the same AFAIK).

 just like I don't know what to do with 1.7-pre1 translations which are
 already out of date.

Add them to the CVS, please, and distribute them together with the next
wget release..

  Next time I'll wait whether you'll send an request to
  [EMAIL PROTECTED]
 
 I didn't even know about that address.  I'll have to, once again, read
 up on the exact TP procedures.

Good idea.  You can start here:

 http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html

-- 
work : [EMAIL PROTECTED]  |   ,__o
 : http://www.suse.de/~ke/ | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)



Re: wget/src/ftp-ls.c: tiny typo

2001-06-04 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 But...  The Wget 1.6 branch exists, and contains minor bugfixes,
 including changed strings.  (I gave up on 1.6.1 because of the
 imminent 1.7 release.)

Reasonable.  Then there's no need to care about still incoming
translations for 1.6.

 If I were to release 1.6.1 with the 1.6 translations, they would once
 again be incorrect.

You could ask [EMAIL PROTECTED] to ask the translations team
to have a look at the 1.6.1 message files.

-- 
work : [EMAIL PROTECTED]  |   ,__o
 : http://www.suse.de/~ke/ | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)



Re: wget/src/ftp-ls.c: tiny typo

2001-06-03 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 The strategy of re-releasing the whole package shares many of the
 flaws with the strings freeze strategy.  Specifically, I would be
 tempted to include bug fixes and string changes into such a
 re-released package.

Would be okay with me.  Just increase the version number (reserve the
first 3 numbers for programming realated issue and the 4th number for
translations):

1.7 The normal forthcoming release.

Then

1.7.0.1 Only translations added

or

1.7.1   Release with bug fixes (and with new translations)

If it was needed to release 1.7.1 and further translations will arrive,
release

1.7.1.1 That's the bug fix release with new translations.

 Unbundling translations has the additional benefit that people who
 don't care about translations (*gasp*) never need to deal with them.

We'll go this way sooner or later; IMO, the time doesn't have come.

 I really cannot understand how an additional TAR file would be an
 irritation to *everyone*.  The programmers, the translators, and the
 users would never even notice it!

Might be part of the problem.  programmers just get familiar with how
it works; maybe, they are not fond of the idea to maintain additional
tar files.  At the moment it's guaranteed it just works (widely
supported by automake, autoconf and gettext plus the robot).

 Compare that to the current situation where all of Wget's translations
 except the Croatian one are *guaranteed* to be incomplete!

Not necessarily.  Interested parties can have a look at
www.iro.umontreal.ca and fetch updated files.

 Francois Pinard has dismissed my idea out of hand.  Sometimes I get
 the feeling that the Translation Project is extremely closed to new
 ideas.

No, not at all.  But it's a lot of work to arrange all the
infrastructure for all the i18n/l10n business.  At the moment we (Martin
v. Löwis and me, with background support by François) are trying to get
the whole project fly again: we've to test gettext, support the teams,
support new translators who want to establish a new team, sort out
copyright issues, add new software packages, keeping track of changing
email addresses and web and FTP references, update/fix the robot
software.  Then we'll have to update the texts of François' website and
we've to work out a scheme to hand out more work to the so called team
leaders (that's a big permission/security problem).

If this is done we can start to change the workflow.  Of course, we can
start now to collect all ideas and to assign priorities.

 Several years ago when I decided to not bundle gettext with Wget, it
 was considered almost unthinkable.  Today it is becoming an
 established practice.

;)  For Linux this might work...

 Sometimes I wish the TP people would listen to suggestions with a more
 attentive ear.

Be assured, we do.  Of course, François also did listen.  Actually, he
collected and sorted all the different mails (proposals, support
requests, etc.); all things are in a pretty good condition as handed out
by François.  Now we're trying to cut down the backlog.  I'm sure this
will not take too long.

I guess I can start to think seriously about improvement proposals the
next month.  This doesn't mean the improvement will come true 2 months
later ;)

Hope this helps for the moment.

-- 
work : [EMAIL PROTECTED]  |   ,__o
 : http://www.suse.de/~ke/ | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)



Re: wget/src/ftp-ls.c: tiny typo

2001-06-03 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 Maybe a more in-depth investigation is needed?  I really don't see a
 single reason why the ls/sed trick Wget employs shouldn't work for any
 other Autoconf-based tool.

Using wildcards is inherently dangerous.  I think all source files and
all installable files ought to be listed explicitly.

-- 
work : [EMAIL PROTECTED]  |   ,__o
 : http://www.suse.de/~ke/ | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)



wget/src/ftp-ls.c: tiny typo

2001-06-02 Thread Karl Eichwalder

2001-06-03  Karl Eichwalder  [EMAIL PROTECTED]

* ftp-ls.c (ftp_parse_ls): Fix typo.

--- wget/src/ftp-ls.c.~1.18.~   Sun Jun  3 07:32:03 2001
+++ wget/src/ftp-ls.c   Sun Jun  3 07:33:39 2001
@@ -785,7 +785,7 @@
   return ftp_parse_unix_ls (file, TRUE);
 default:
   logprintf (LOG_NOTQUIET, _(\
-Usupported listing type, trying Unix listing parser.\n));
+Unsupported listing type, trying Unix listing parser.\n));
   return ftp_parse_unix_ls (file, FALSE);
 }
 }

Diff finished at Sun Jun  3 07:34:43

-- 
work : [EMAIL PROTECTED]  |   ,__o
 : http://www.suse.de/~ke/ | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)




Re: translations 1.7? (Re: Question)

2001-05-31 Thread Karl Eichwalder

On 30 May 2001, Hrvoje Niksic wrote:

 You can get the pre-release from
 ftp://gnjilux.srk.fer.hr/pub/unix/util/wget/.betas/wget-1.7-pre1.tar.gz.

Thanks, I installed the new .pot file from 1.7-pre1:

http://www.iro.umontreal.ca/contrib/po/HTML/domain-wget.html

Karl





translations 1.7? (Re: Question)

2001-05-30 Thread Karl Eichwalder

On 30 May 2001, Hrvoje Niksic wrote:

 Yes, but you need the version 1.7, which is about to be released.

If a pre-release is available I'd like to install the .pot file of this
pre-release package on the Translation Robot site
(http://www.iro.umontreal.ca/contrib/po/HTML/).

Of course, I can wait if you think it's too early.

Karl





Re: wget.pot and translations

2001-05-08 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 Since the other methods have obviously failed, here is the pot file:
 
 http://jagor.srce.hr/~hniksic/wget/wget.pot

I'm very sorry about all the trouble you all have had with the
Translation Robot.  Now I've learnt from François how to feed this
nice system (at least, it looks as if I'm able to update existing
projects).

I just run wget-1.6 through the robot (mainly for real live testing).
Now it should be possible to submit .pot files as usual (human
intervention by me (or Martin v. Löwis) is still needed to put those
files in place -- we'll try our best).  Martin will mainly take care
about the technical details; I'll try to do the paper work, files
processing and the like.

Thanks again to François Pinard for implementing and establishing this
great system (he's still acting in the background; this will help a
lot!).

All the best,
Karl

-- 
Linux Frechet 2.2.18 #1 Fri Jan 19 22:10:35 GMT 2001 i686 unknown
  7:54pm  up 5 days,  2:27, 11 users,  load average: 0.04, 0.03, 0.00
 work:  [EMAIL PROTECTED]
Karl Eichwalder  home: [EMAIL PROTECTED]



Re: Support for DESTDIR while installing

2001-01-20 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 Only if you haven't run `make' before.  With Wget, it's perfectly safe
 to say:
 
 $ make   # assumes regular prefix
 ... build finishes ...
 $ make install prefix=/something/different   # same as DESTDIR=...

Okay, but it isn't userfriendly to ask the user to use different values
for the same variable at different stages of the configuration,
compilation and installation precess.

Yes, I admit wget fulfills the Coding Standards as written; but I see
possibilities to improve it even more.

-- 
work : [EMAIL PROTECTED]  |   ,__o
 : http://www.suse.de/~ke/ | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)



Re: Support for DESTDIR while installing

2001-01-20 Thread Karl Eichwalder

Russ Allbery [EMAIL PROTECTED] writes:

 Karl Eichwalder [EMAIL PROTECTED] writes:
  Hrvoje Niksic [EMAIL PROTECTED] writes:

  $ make   # assumes regular prefix
  ... build finishes ...
  $ make install prefix=/something/different   # same as DESTDIR=...

  Okay, but it isn't userfriendly to ask the user to use different values
  for the same variable at different stages of the configuration,
  compilation and installation precess.

 No, every package *should* support the above sequence.

Yes.  Look at Tom's mail; he confirms it's easy to support the prefix
and the DESTDIR way at the same time ;)  The hard part is to get the
prefix way right.

 It's pretty much the standard way of doing this, and tons of package
 management software in the class stow uses this or something like it
 (I don't know if stow in particular does, but I know that a lot of
 stow-like things do).

Yes, the nice thing with DESTDIR is you only have to say:

./configure --prefix=/gnu/usr --sysconfdir=/gnu/etc
make
make DESTDIR=/var/tmp/package-root install

And without DESTDIR support you would have to repeat
"/var/tmp/package-root" for every directory:

./configure --prefix=/gnu/usr --sysconfdir=/gnu/etc
make
make prefix=/var/tmp/package-root/gnu/usr \
 sysconfdir=/var/tmp/package-root/gnu/etc \
 install

and you've to hope the rules are carefully arranged and will not touch
files during the install step again (in this regard wget is a perfect
package, too!).

-- 
work : [EMAIL PROTECTED]  |   ,__o
 : http://www.suse.de/~ke/ | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)