I would like to point out that people ASSUMED I meant that pacman would
cull through the PKGBUILDs *if* the change info was added at the end of
same.
That is an assumption and is *NOT* necessarily correct.
Pacman does *not* have to be the info culling mechanism. Personally a
simple bash script c
I was answering to a thread that had veered off into suggesting the
PKGBUILD as a means to provide this explanation for upgrade, therefore,
my references and PKGBUILD specific. I personally would prefer a mailing
list option.
cactus wrote:
I would say that informing the user community as to the
I would say that informing the user community as to the reason a package
is updated is a needed feature. Every distribution I can think of has a
changelog for packages. Most have security update channels of some form
or another. Be it mailing list, rss feed, or something.
I made no distinction
I agree.
Pacman is a good package management system as it is. It is not
logical to extend the uses of pacman away from it's primary job, since
this will only increase it's size and features through time. Bloateritis
should be nipped in the bud; prevention is better than cure.
And for those
Compared to RPM, Pacman is pgk-management without bells and
whistles. There are a lot nice-to-have features people will request.
But to keep Pacman small and beautiful and the whole system flexible
all those features should be implemented outside of pacman if possible.
There a lot of options:
*
> Le Friday 06 May 2005 16:09, [EMAIL PROTECTED] a écrit :
>> Actually this is a *wonderful* idea. I would like to see something
>> added in the PKGBUILD at the end.
>
> PKGBUILD's schould not contain any changelogs
>
> Damir
>
> --
> Too much of a good thing is wonderful.
>
> -- Mae West.
Le Friday 06 May 2005 20:46, Pierre Schmitz a écrit :
> > hotplug @dbus @hal
>
> Well, this is not very usefull because hotplug is the demon which needs
> a lot of time. dbus and hal start up fast.
yes, but also if you group them, they hotplug will still need time to load
(the only simplification
> > > So, what about an easy grouping-mechanism? For example:
> > >(syslog @(hotplug dbus hal !alsa) @httpd !cups)
> > you can use
> > hotplug @dbus @hal
> Well, this is not very usefull because hotplug is the demon which needs a lot
> of time. dbus and hal start up fast.
Ok, ummm you can ge
Well, funny thing, but I think I get it running. If everything works fine I
will distribute a working script soon.
Pierre
Am Freitag, 6. Mai 2005 20:46 schrieb Pierre Schmitz:
> Am Freitag, 6. Mai 2005 20:15 schrieb Damir Perisa:
> > Le Friday 06 May 2005 19:20, Pierre Schmitz a écrit :
> > > Bu
Am Freitag, 6. Mai 2005 20:15 schrieb Damir Perisa:
> Le Friday 06 May 2005 19:20, Pierre Schmitz a écrit :
> > But this does not help a lot when there are scripts which depend on
> > each other. For example you could not start dbus and hal before hotplug
> > is ready.
>
> you can use
>
> hotplug @
That would require a total rewrite no?
I would say it'd be better to stay with your first example of:
hotplug @hal @dbus
> the implementation can be really tricky (to be also failsave) ... what can
> be done is using perl instead of bash. it's a 2d-array what you
> suggest if you manage t
Le Friday 06 May 2005 19:20, Pierre Schmitz a écrit :
> But this does not help a lot when there are scripts which depend on
> each other. For example you could not start dbus and hal before hotplug
> is ready.
you can use
hotplug @dbus @hal
or
@hotplug @dbus @hal
> So, what about an easy g
On 5/6/05, RedShift <[EMAIL PROTECTED]> wrote:
> Maybe ArchLinux could switch to initng for 0.8, or when kernel 2.8 comes
> out (I can imagine there will be alot of package-fixing for initng and
> work to port the current scripts to the initng structure)
I'm going to make a package for initng, for
Hello,
there is still a patch which makes it possible to run demons in background by
adding an @ in front of it. (implemented by adding an & to the demon-script)
But this does not help a lot when there are scripts which depend on each
other. For example you could not start dbus and hal before h
It's actually worth checking the forum once or twice a month :-)
Discussions about initng:
http://bbs.archlinux.org/viewtopic.php?t=12183
http://bbs.archlinux.org/viewtopic.php?t=12188
fredagen den 6 maj 2005 18.46 skrev RedShift:
> I just stumbled over this website:
> http//jw.dyndns.org/initng
>
I just stumbled over this website:
http//jw.dyndns.org/initng
Seems very interesting, initng focusses on fast booting and monitoring
services, and overall a great replacement for sysvinit. Is anyone
interested in making a package for it?
Maybe ArchLinux could switch to initng for 0.8, or when ke
I agree... PKGBUILDs are clean and easy to read... adding more info would
be a bad idea
pacman, however, could get changelog info from CVS
What I would like to see is the ability to load from CVS the changelog of
the actual program, instead of just the package changelog... but that
would require
Le Friday 06 May 2005 16:09, [EMAIL PROTECTED] a écrit :
> Actually this is a *wonderful* idea. I would like to see something
> added in the PKGBUILD at the end.
PKGBUILD's schould not contain any changelogs
Damir
--
Too much of a good thing is wonderful.
-- Mae West.
pgpVY8QcGO1ZW.p
Actually this is a *wonderful* idea. I would like to see something added
in the PKGBUILD at the end.
Very best regards;
Bob Finch
> Would it be possible to get some sort of mechanism that reports not only
> the packages updated (like the main page rss), but provides some short
> reason as to w
Le Friday 06 May 2005 14:20, Odin Omdal a écrit :
> But that is kinda inefficent. Hm. Should've been possible to write a
> bash-script that collects the info from CVS and displays it - so one
> musn't fire up a browser and navigate trough loads of packages.
good idea: making an RSS-feed out of cvs
Kevin,
Replaces won't fix this as it's the same package, but force=y would. If
you don't mind, could you release a -2 with force=y?
Dale
On Fri, 2005-05-06 at 09:12 -0400, K Piche wrote:
> Version 1.99.1 (1999) is newer than 9708 (1997) except the version
> number format changed. Perhaps a re
Version 1.99.1 (1999) is newer than 9708 (1997) except the version
number format changed. Perhaps a replaces= would fix this.
k
On Thu, 2005-05-05 at 23:22 -0700, cactus wrote:
> Would it be possible to get some sort of mechanism that reports not only
> the packages updated (like the main page r
But that is kinda inefficent. Hm. Should've been possible to write a
bash-script that collects the info from CVS and displays it - so one
musn't fire up a browser and navigate trough loads of packages.
On 5/6/05, Jürgen Hötzel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I read the CVS-Logs/Diffs:
>
> h
Hi,
I read the CVS-Logs/Diffs:
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/
Jürgen
> Would it be possible to get some sort of mechanism that reports not only
> the packages updated (like the main page rss), but provides some short
> reason as to why it was updated?
> Even something like: "Fix
24 matches
Mail list logo
