On 06/02/2016 15:30, Jon Turney wrote:
On 06/02/2016 14:29, Ken Brown wrote:
Jon, any further thoughts about this? texinfo-6.1 has just been
released, so I can go ahead with adding the postinstall script as soon
as we decide what it should do in the case of a missing
On 06/02/2016 14:29, Ken Brown wrote:
On 1/29/2016 9:53 AM, Ken Brown wrote:
On 1/29/2016 9:22 AM, Jon Turney wrote:
On 28/01/2016 20:22, Eric Blake wrote:
On 01/28/2016 01:17 PM, Ken Brown wrote:
Second, why is the second line needed, i.e., under what circumstances
would it be expected to
On 1/29/2016 9:53 AM, Ken Brown wrote:
On 1/29/2016 9:22 AM, Jon Turney wrote:
On 28/01/2016 20:22, Eric Blake wrote:
On 01/28/2016 01:17 PM, Ken Brown wrote:
install-info $f /usr/share/info/dir ||
install-info --entry="* $$f ($f): $$f" $$f /usr/share/info/dir
First, what do those
On 28/01/2016 20:22, Eric Blake wrote:
On 01/28/2016 01:17 PM, Ken Brown wrote:
install-info $f /usr/share/info/dir ||
install-info --entry="* $$f ($f): $$f" $$f /usr/share/info/dir
First, what do those double dollar signs mean?
If this is from a Makefile snippet, it says that $f is
> On Jan 28 19:06, Achim Gratz wrote:
> > Jon Turney writes:
> > >>> You could read the md5sums into variables instead and just compare the
> > >>> resulting strings within bash. Otherwise we'd have to add diffutils to
> > >>> the Base category.
> > >
> > > I've made this change.
> >
> > Thank
On 1/29/2016 2:17 PM, Achim Gratz wrote:
Ken Brown writes:
[…]
Now for something completely different: when you pull that script into
some info package, could you please swicth it to dash?
Will do.
Ken
Ken Brown writes:
[…]
Now for something completely different: when you pull that script into
some info package, could you please swicth it to dash?
Most if not all of the postinstall scripts would probably work with
dash, so if you#re working on one you should check and switch it if
appropriate.
Jon Turney writes:
>>> You could read the md5sums into variables instead and just compare the
>>> resulting strings within bash. Otherwise we'd have to add diffutils to
>>> the Base category.
>
> I've made this change.
Thank you very much.
> As an interim solution, I've adopted
On 01/28/2016 11:42 AM, Ken Brown wrote:
> On 1/28/2016 12:33 PM, Jon Turney wrote:
>> Future work: I can't see any reason why this script now needs an
>> independent existence, so it could be absorbed by the info package.
>
> That's fine with me. There will be a new version of texinfo soon
On 1/28/2016 3:06 PM, Eric Blake wrote:
> On 01/28/2016 11:42 AM, Ken Brown wrote:
>> On 1/28/2016 12:33 PM, Jon Turney wrote:
>>> Future work: I can't see any reason why this script now needs an
>>> independent existence, so it could be absorbed by the info package.
>>
>> That's fine with me.
On 01/28/2016 01:17 PM, Ken Brown wrote:
>>>install-info $f /usr/share/info/dir ||
>>>install-info --entry="* $$f ($f): $$f" $$f /usr/share/info/dir
>>>
>>> First, what do those double dollar signs mean?
>>
>> If this is from a Makefile snippet, it says that $f is a make variable,
>> while
On 26/11/2015 10:11, Corinna Vinschen wrote:
On Nov 24 19:44, Achim Gratz wrote:
Jon Turney writes:
So, should we try to guard against that (installations on a USB stick
are probably the only practical occurence these days)? I wouldn't mind
if we just unconditionally rebuild on FAT(32).
On 1/28/2016 12:33 PM, Jon Turney wrote:
Future work: I can't see any reason why this script now needs an
independent existence, so it could be absorbed by the info package.
That's fine with me. There will be a new version of texinfo soon (it's
currently in pretest), so we can make the
On Jan 28 19:06, Achim Gratz wrote:
> Jon Turney writes:
> >>> You could read the md5sums into variables instead and just compare the
> >>> resulting strings within bash. Otherwise we'd have to add diffutils to
> >>> the Base category.
> >
> > I've made this change.
>
> Thank you very much.
+1
Hey Guys,
On Nov 24 19:44, Achim Gratz wrote:
> Jon Turney writes:
> >> So, should we try to guard against that (installations on a USB stick
> >> are probably the only practical occurence these days)? I wouldn't mind
> >> if we just unconditionally rebuild on FAT(32).
> >
> > Thinking this
Corinna Vinschen writes:
> I trust both of you to do the right thing. My question here is only,
> can we get a solution soon so we can get rid of the old upset method for
> the info files? Achim, how long would it take to create the same
> solution for info you're using for rebase? Would it
Jon Turney writes:
>> So, should we try to guard against that (installations on a USB stick
>> are probably the only practical occurence these days)? I wouldn't mind
>> if we just unconditionally rebuild on FAT(32).
>
> Thinking this over, it doesn't seem that hard to use a hash to
> determine if
On 23/11/2015 18:54, Achim Gratz wrote:
Jon Turney writes:
So, this is actually quite straightforward to write, and
/etc/postinstall/0p_update-info-dir.sh becomes the attached.
Can this be relied on for all possible file systems?
Not on FAT. But then again, FAT is not really a filesystem,
Jon Turney writes:
> So, this is actually quite straightforward to write, and
> /etc/postinstall/0p_update-info-dir.sh becomes the attached.
>
>>> Can this be relied on for all possible file systems?
>>
>> Not on FAT. But then again, FAT is not really a filesystem, rather just
>> a failed try.
>
On 20/10/2015 11:21, Corinna Vinschen wrote:
On Oct 19 19:21, Achim Gratz wrote:
Corinna Vinschen writes:
I agree. Actually, considering that the info files are stored in just a
single well-known directory, /usr/share/info(*), and further considering
that updated files are rewritten when
On 15/10/2015 19:01, Achim Gratz wrote:
Jon Turney writes:
I still don't think the triggers should be implemented or at least not
in the way you've been proposing.
Can you explain the reason why?
Triggers need to be coordinated among packages and we currently don't
have an infrastructure
On Oct 19 19:21, Achim Gratz wrote:
> Corinna Vinschen writes:
> > I agree. Actually, considering that the info files are stored in just a
> > single well-known directory, /usr/share/info(*), and further considering
> > that updated files are rewritten when overwritten, shouldn't it be entirely
>
On Oct 12 14:16, Jon Turney wrote:
> On 22/09/2015 16:52, Jon Turney wrote:
> >(Further note: autodep is broken in upset. Many package which should have a
> >dependency on _update-info-dir do not have one, and only 19 packages do, so
> >this
> >is not working as intended at the moment.
> >
>
> On Oct 12 14:16, Jon Turney wrote:
> > On 22/09/2015 16:52, Jon Turney wrote:
> > >(Further note: autodep is broken in upset. Many package which should have
> > >a
> > >dependency on _update-info-dir do not have one, and only 19 packages do,
> > >so this
> > >is not working as intended at the
On 12/10/2015 18:38, Achim Gratz wrote:
Jon Turney writes:
On 22/09/2015 16:52, Jon Turney wrote:
[...]
As for your patches, I think that the first two (getting rid of the
regex engine and the incomplete implementation of autodep: lines) are
non-controversial and should be applied.
Ok,
Jon Turney writes:
>> I still don't think the triggers should be implemented or at least not
>> in the way you've been proposing.
>
> Can you explain the reason why?
Triggers need to be coordinated among packages and we currently don't
have an infrastructure for that. And implementing just a
On 22/09/2015 16:52, Jon Turney wrote:
(Further note: autodep is broken in upset. Many package which should have a
dependency on _update-info-dir do not have one, and only 19 packages do, so this
is not working as intended at the moment.
Yes, this means that the autodep on the cygwin package
Jon Turney writes:
> On 22/09/2015 16:52, Jon Turney wrote:
>> (Further note: autodep is broken in upset. Many package which should have a
>> dependency on _update-info-dir do not have one, and only 19 packages do, so
>> this
>> is not working as intended at the moment.
>>
>> Yes, this means
On 22/09/2015 18:32, Achim Gratz wrote:
Jon Turney writes:
Since we now have scripts which run on every setup run, a package which requires
another package to do some work after it is installed or uninstalled can create
a file to act as a trigger for that to happen.
There aren't any
[replying to the right list, this time]
On 22/09/2015 18:32, Achim Gratz wrote:
Jon Turney writes:
Since we now have scripts which run on every setup run, a package which requires
another package to do some work after it is installed or uninstalled can create
a file to act as a trigger for
Jon Turney writes:
> [replying to the right list, this time]
I was slightly bewildered by that former reply… :-)
> On 22/09/2015 18:32, Achim Gratz wrote:
> I thought that permanent postinstall scripts run even when no packages
> are being installed, or only packages are being removed, so they
Jon Turney writes:
> This is an attempt at a setup feature which will allow the removal of the
> final
> use of 'incver_ifdep' in setup.hint, by _update-info-dir package.
The easiest way to go about this would be to have _update-info-dir
install a perpetual postinstall script that does the very
This is an attempt at a setup feature which will allow the removal of the final
use of 'incver_ifdep' in setup.hint, by _update-info-dir package.
See the discussions starting at around [1],[2] and following, although this
takes a slightly different approach.
To be clear: IMHO, this
33 matches
Mail list logo
