[arch-dev-public] Fix texinfo-based depcycles in core

Aaron Griffin aaronmgriffin at gmail.com
Wed Jan 28 15:04:20 EST 2009


On Wed, Jan 28, 2009 at 11:57 AM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Wed, Jan 28, 2009 at 9:55 AM, Dan McGee <dpmcgee at gmail.com> wrote:
>> On Wed, Jan 28, 2009 at 9:44 AM, Allan McRae <allan at archlinux.org> wrote:
>>> Aaron Griffin wrote:
>>>>
>>>> On Tue, Jan 27, 2009 at 6:30 PM, Allan McRae <allan at archlinux.org> wrote:
>>>>
>>>>>
>>>>> Aaron Griffin wrote:
>>>>>
>>>>>>
>>>>>> On Tue, Jan 27, 2009 at 2:59 PM, Aaron Griffin <aaronmgriffin at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 27, 2009 at 2:50 PM, Dan McGee <dpmcgee at gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 27, 2009 at 2:20 PM, Aaron Griffin
>>>>>>>> <aaronmgriffin at gmail.com>
>>>>>>>> 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.


More information about the arch-dev-public mailing list