On Tue, Jan 27, 2009 at 2:50 PM, Dan McGee wrote:

On Tue, Jan 27, 2009 at 2:20 PM, Aaron Griffin wrote:

...

This idea is Thomas', I take no credit, except that I actually wrote it up.

The idea: texinfo, on install, processes all info files. bash and glibc (and, likely, other packages in core) no longer need to depend on texinfo, but should check for install-info in the scriptlets before running.

a) user installs bash and glibc. No info files are processed, texinfo not installed user then installs texinfo, all info files are processed b) user installs texinfo first (somehow) user then installs bash, info files processed due to existence of install-info c) user follows case a or b user upgrades bash or glibc, info files processed as normal due to presence of install-info

Any issues with this? See attached patch. Please review. If possible, this needs to go to core before we release the ISOs.

Seems reasonable for now. Basically any package in core should 1) not depend on texinfo 2) attempt to call install-info if it has info pages AND install-info is found?

Yeah I guess, technically all packages should check for install-info before actually doing anything - it's only proper. Allan, can we get the proto file updated with the -x check (and full paths) ?

On Tue, Jan 27, 2009 at 6:07 PM, Aaron Griffin wrote:

On Tue, Jan 27, 2009 at 2:59 PM, Aaron Griffin wrote:

...

On Tue, Jan 27, 2009 at 2:50 PM, Dan McGee wrote:

...

On Tue, Jan 27, 2009 at 2:20 PM, Aaron Griffin wrote:

...

This idea is Thomas', I take no credit, except that I actually wrote it up.

The idea: texinfo, on install, processes all info files. bash and glibc (and, likely, other packages in core) no longer need to depend on texinfo, but should check for install-info in the scriptlets before running.

a) user installs bash and glibc. No info files are processed, texinfo not installed user then installs texinfo, all info files are processed b) user installs texinfo first (somehow) user then installs bash, info files processed due to existence of install-info c) user follows case a or b user upgrades bash or glibc, info files processed as normal due to presence of install-info

Any issues with this? See attached patch. Please review. If possible, this needs to go to core before we release the ISOs.

Seems reasonable for now. Basically any package in core should 1) not depend on texinfo 2) attempt to call install-info if it has info pages AND install-info is found?

Yeah

I guess, technically all packages should check for install-info before actually doing anything - it's only proper.

Allan, can we get the proto file updated with the -x check (and full paths) ?

Any opinions on this (well, the second email, with the fixed patch) ?

Seems fine to me. Good catch on the executable not being there. -Dan

On Tue, Jan 27, 2009 at 6:30 PM, Allan McRae wrote:

Aaron Griffin wrote:

...

On Tue, Jan 27, 2009 at 2:59 PM, Aaron Griffin wrote:

...

On Tue, Jan 27, 2009 at 2:50 PM, Dan McGee wrote:

...

On Tue, Jan 27, 2009 at 2:20 PM, Aaron Griffin wrote:

...

This idea is Thomas', I take no credit, except that I actually wrote it up.

The idea: texinfo, on install, processes all info files. bash and glibc (and, likely, other packages in core) no longer need to depend on texinfo, but should check for install-info in the scriptlets before running.

a) user installs bash and glibc. No info files are processed, texinfo not installed user then installs texinfo, all info files are processed b) user installs texinfo first (somehow) user then installs bash, info files processed due to existence of install-info c) user follows case a or b user upgrades bash or glibc, info files processed as normal due to presence of install-info

Any issues with this? See attached patch. Please review. If possible, this needs to go to core before we release the ISOs.

Seems reasonable for now. Basically any package in core should 1) not depend on texinfo 2) attempt to call install-info if it has info pages AND install-info is found?

Yeah

I guess, technically all packages should check for install-info before actually doing anything - it's only proper.

Allan, can we get the proto file updated with the -x check (and full paths) ?

Any opinions on this (well, the second email, with the fixed patch) ?

That fix looks good to me. How long does it take to scan all info pages when reinstalling texinfo on a system with a decent number of packages installed?

I will update the proto file soon.

The "scan all" is only done on _install_ not on upgrade. On upgrade it just does it's thing with its own info files

On Wed, Jan 28, 2009 at 9:44 AM, Allan McRae wrote:

Aaron Griffin wrote:

...

On Tue, Jan 27, 2009 at 6:30 PM, Allan McRae wrote:

...

Aaron Griffin wrote:

...

On Tue, Jan 27, 2009 at 2:59 PM, Aaron Griffin wrote:

...

On Tue, Jan 27, 2009 at 2:50 PM, Dan McGee wrote:

...

On Tue, Jan 27, 2009 at 2:20 PM, Aaron Griffin wrote:

> > This idea is Thomas', I take no credit, except that I actually wrote > it > up. > > The idea: > texinfo, on install, processes all info files. bash and glibc (and, > likely, other packages in core) no longer need to depend on texinfo, > but should check for install-info in the scriptlets before running. > > a) user installs bash and glibc. No info files are processed, texinfo > not installed > user then installs texinfo, all info files are processed > b) user installs texinfo first (somehow) > user then installs bash, info files processed due to existence of > install-info > c) user follows case a or b > user upgrades bash or glibc, info files processed as normal due to > presence of install-info > > Any issues with this? See attached patch. Please review. If possible, > this needs to go to core before we release the ISOs. > >

Seems reasonable for now. Basically any package in core should 1) not depend on texinfo 2) attempt to call install-info if it has info pages AND install-info is found?

Yeah

I guess, technically all packages should check for install-info before actually doing anything - it's only proper.

Allan, can we get the proto file updated with the -x check (and full paths) ?

Any opinions on this (well, the second email, with the fixed patch) ?

That fix looks good to me. How long does it take to scan all info pages when reinstalling texinfo on a system with a decent number of packages installed?

I will update the proto file soon.

The "scan all" is only done on _install_ not on upgrade. On upgrade it just does it's thing with its own info files

OK. I noticed you have use the leading / when using the full path to the install-info binary (i.e. /usr/bin/info-install vs. usr/bin/info-install) Other prototype install scripts do not use the leading slash. Looking in the PKGBUILD man page, it is not specified which is right. So, does this matter and if so, which is actually correct?

We always chroot into the root install directory, and also cwd to /, so it is probably better to specify the path without a leading slash. -Dan

On Wed, Jan 28, 2009 at 11:57 AM, Aaron Griffin wrote:

On Wed, Jan 28, 2009 at 9:55 AM, Dan McGee wrote:

...

On Wed, Jan 28, 2009 at 9:44 AM, Allan McRae wrote:

...

Aaron Griffin wrote:

...

On Tue, Jan 27, 2009 at 6:30 PM, Allan McRae wrote:

...

Aaron Griffin wrote:

...

On Tue, Jan 27, 2009 at 2:59 PM, Aaron Griffin wrote:

> > On Tue, Jan 27, 2009 at 2:50 PM, Dan McGee wrote: > > >> >> On Tue, Jan 27, 2009 at 2:20 PM, Aaron Griffin >> >> wrote: >> >> >>> >>> This idea is Thomas', I take no credit, except that I actually wrote >>> it >>> up. >>> >>> The idea: >>> texinfo, on install, processes all info files. bash and glibc (and, >>> likely, other packages in core) no longer need to depend on texinfo, >>> but should check for install-info in the scriptlets before running. >>> >>> a) user installs bash and glibc. No info files are processed, texinfo >>> not installed >>> user then installs texinfo, all info files are processed >>> b) user installs texinfo first (somehow) >>> user then installs bash, info files processed due to existence of >>> install-info >>> c) user follows case a or b >>> user upgrades bash or glibc, info files processed as normal due to >>> presence of install-info >>> >>> Any issues with this? See attached patch. Please review. If possible, >>> this needs to go to core before we release the ISOs. >>> >>> >> >> Seems reasonable for now. Basically any package in core should >> 1) not depend on texinfo >> 2) attempt to call install-info if it has info pages AND install-info >> is >> found? >> >> > > Yeah > > I guess, technically all packages should check for install-info before > actually doing anything - it's only proper. > > Allan, can we get the proto file updated with the -x check (and full > paths) ? > >

Any opinions on this (well, the second email, with the fixed patch) ?

That fix looks good to me. How long does it take to scan all info pages when reinstalling texinfo on a system with a decent number of packages installed?

I will update the proto file soon.

The "scan all" is only done on _install_ not on upgrade. On upgrade it just does it's thing with its own info files

OK. I noticed you have use the leading / when using the full path to the install-info binary (i.e. /usr/bin/info-install vs. usr/bin/info-install) Other prototype install scripts do not use the leading slash. Looking in the PKGBUILD man page, it is not specified which is right. So, does this matter and if so, which is actually correct?

We always chroot into the root install directory, and also cwd to /, so it is probably better to specify the path without a leading slash.

Why? If one of those things ever changed, I imaged it'd be the 'cd', not the chroot part. The absolute path will always work, whereas the relative path will not.

Either way though, bikeshedding here - Allan, use your discretion.

Anyone want to help me apply this patch today, rebuild, and put these packages in testing? I can do texinfo and bash, but don't know if there's anything I need to know about glibc.

Rebuilding everything now. glibc taks a long time 8) For the record, the empty "return" doesn't work. It appears to return the last value of $? in that case, so it still reports the scriptlet failing. "return 0" should be used.