Re: npm and bundled modules

[aredridel]

> On 10 Sep 2016, at 17:46, Paweł A. Gajda  wrote:
> 
> Our npm is packaged wihtout bundled npm modules, what is generally good and
> maybe elegant, but it's just hard to maintain as there is over 70 node
> modules (npm 3.x) it depends on. That is probably the reason, why npm has
> not been upgraded from 1.x.
> 
> npm itself bundle its dependencies,so, what I like to do is just to bundle
> them into package as well. It just works and would make upgrades much, much
> easier. Any objections?

This is how node apps work in community practice, and doing this would make me 
very, very happy. It's basically meant that I don't use the system versions of 
node and npm at all because they actively fight how node works.

So not just +1 but +100.

(PS. I now work at npm.)

Aria
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: packaging rules

[Aredridel]

On Wed, 2007-08-01 at 22:06 +0200, Cezary Krzyżanowski wrote:
 
 2007/8/1, Patryk Zawadzki [EMAIL PROTECTED]:
 Is there anything against switching all NameObsoletes
 (Obsoletes: gdm
 in kdm etc.) to conflicts or dropping them altogether?
 
 I am the admin and I want to decide what to install with what.
 If I
 want 2 login managers, that's my problem, if I want 3 smtp
 services, 
 that's my problem.
 
 I'd suggest a help notice (I'm not sure is it possible with rpm -- I'd
 say poldek had to do it, as one of the nice features that drag ppl to
 us (mmazur(tm))). Something like: 
 You are trying to install package %{name} which provides %{provides},
 but you've already have a package providing %{provides} installed in
 your system: %{packages_having_the_provided_thing_list}.
 
 If you'd like to install it anyway use the --force option. 
 
 Remember you have to manually configure the %{name} package to have it
 working side by side with %{packages_having_the_provided_thing_list}.
 
 That + implementing + 4 policies in poldek (automatically force,
 automatically ignore without error, automatically fail with error (the
 present poldeks behaviour), ask the user). I *think* some further
 checking is needed, as there will happen situation, when the conflict
 macro means that the packages literally can't be installed in the same
 system side-by-side. 

Using just Provides: makes so much sense to me -- I've wished I could
have both installed at once several times without upgrades semi-silently
removing one. (An arch developer asked me yesterday how PLD handled
this.)

Aria


signature.asc
Description: This is a digitally signed message part
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [RFC] Repository layout change / Zmiana układu repo

[Aredridel]

Jakub Bogusz wrote:
 One more thing: non-specs and template specs need to be moved to some
 other place (scripts/ and templates/ dirs? mirrors and
 additional-md5sums are used by scripts, so they can be together with
 scripts).

   
Call it bin/ and templates/?  It's a good change.

Aria
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Adding a user to CVS (apollotiger)

[Aredridel]

I'd love to add my friend apollotiger to CVS. He's helped me with ruby
and gaim specs off and on, and is using PLD on most of his machines,
building a lot from CVS anyway and finding things to fix.

+1?

From IRC today:
[11:33:11] Aria says “Any objection to adding apollotiger to cvs? He keeps 
helping me with ruby and gaim specs”
[11:33:13] Aria says “?”
[11:36:52] arekm says “you need three +1 on pld-devel-en for that”
[11:37:10] arekm says “shouldn't be a problem anyway”
[11:37:45] shadzik says “Aria, you have my vote !”
[11:37:57] * Aria nods
[11:37:58] shadzik says “of course... that will cost you... :)”
[11:38:01] Aria says “Haha.”
[11:38:02] SamChi says “Aria: just drop a message at devel-en list”
[11:38:04] Aria says “++”
[11:38:07] Aria says “Will do.”
[11:38:31] shadzik says “SamChi, will you add my vote to that list ? i don't 
subscribe devel-en”
[11:38:49] shadzik says “Aria, or just do it by yourself, add my vote +1”
[11:39:02] SamChi says “Aria: He should present himself aswell, just to be sure 
he's subscribed to the list”
[11:39:08] SamChi says “shadzik: than do it”
[11:42:57] shadzik says “Aria, i mean it :) i'm +1 on that idea”
[11:43:36] SamChi says “http://en.wikipedia.org/wiki/User:Apollotiger ?”
[11:47:38] Aria says “Yes.”

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

gnustep-make 2.0.0

[Aredridel]

gnustep-make 2.0.0 allows the option of using FHS paths rather than
Gnustep Flattened or Gnustep deep layouts. Any objection to porting the
few gnustep specs over?

Aria
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Adding a user to CVS (apollotiger)

[Aredridel]

Radoslaw Zielinski wrote:
 I beleve Aria's proposal counts as +1.
 

 True, my mistake.
   
I will definitely help Joshua get up to speed.

Aria
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Bad dependency (Need FTP move/rebuild?)

[Aredridel]

vte-0.14 is missing from th repo (in th-test), but th gnome-terminal
depends on vte = 0.14

Aria


signature.asc
Description: This is a digitally signed message part
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Fwd: SOURCES: multipath-tools-optflags.patch (REMOVED) - obsolete

[Aredridel]

On Sun, 2006-07-30 at 22:38 +0300, Elan Ruusamäe wrote:
 if you didn't bother to update the patch it does not mean it's obsolete!!!
 

The mainline source now has overridable OPTFLAGS. The patch is obsolete.

Aria

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: SOURCES: multipath-tools-selinux.patch (NEW) - added

[Aredridel]

  I'll do that from now on. I've added the pclean command to the SOURCES
  repository.
 you can have automatics in CVS too, but having automatics there's always risk 
 they work wrong...

Yeah, I prefer something that can be confirmed à la SPECS/adapter. It's
really an excellent tool.

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: SPECS: gnome-applet-deskbar.spec - add optional dep for beagle; no...

[Aredridel]

On Fri, 2006-07-21 at 06:59 +0200, Fryderyk Dziarmagowski wrote:
 --- aredridel [EMAIL PROTECTED] wrote:
 
  Author: aredridelDate: Thu Jul 20 23:25:36 2006 GMT
  Module: SPECS Tag: HEAD
   Log message:
  - add optional dep for beagle; no configure option for it
 [...]
  +%{?with_beagle:BuildRequires:  beagle-devel}
 
 this is bogus change. beagle support is detected at runtime and
 requires python moudle to run, beagle or beagle-devel are NOT required
 at build time.

Aha! I see now. It acted like a build-time dependency the way it didn't
work at first for me. Thanks.

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: faubackup.spec

[Aredridel]

On Mon, 2006-06-19 at 20:47 +0200, Tomasz Grobelny wrote:
 Dnia Saturday, 17 of June 2006 01:54, Tomasz Grobelny napisał:
  Not yet tested in production environment.
 Thanks for adding to CVS. I've just started testing and it seems that BR: 
 popt-devel and R: popt need to be added (though I don't have a system without 
 popt to test that). Should I send a patch or is this info enough?

That's enough, since one-line changes are as easy as a patch.

popt should be detected as a dependency at build time, but the -devel
package cannot.


signature.asc
Description: This is a digitally signed message part
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: 4/5 builders down, TH going single-arch

[Aredridel]

On Wed, 2006-06-07 at 23:09 +0200, Mariusz Mazur wrote:
 There was a tragic accident resulting in four out of five th builders getting 
 seriously mutilated. The lucky survivor is x86-64. Since it's generally 
 agreed that this is currently the best architecture around and bound to 
 become the most popular, I've decided to have pld3.0 support only one arch -- 
 the x86-64. Just imagine the benefits of not having to support all of those 
 archs!
 
 
 (Fact of the matter is, those builders got seriously gutted, so it'll take a 
 couple of days to get them back in shape.)

Eek. Glad to know.

Go amd64!


signature.asc
Description: This is a digitally signed message part
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: RPM changelog

[Aredridel]

On Thu, 2006-04-27 at 19:52 +0300, Elan Ruusamäe wrote:
 On Thursday 27 April 2006 19:29, Elan Ruusamäe wrote:
  On Thursday 27 April 2006 15:37, Marcin Król wrote:
but while we were discussing migration to svn it was stated
that we really need complete changelog. always.
  
   Wait a second. I got lost. glen wants to cut changelog in CVS/SVN or in
   packages at build time? If in specs, then some of them have already been
   cut manually. If in rpms, isn't it pointless?
 
  in binary rpm's. why pointless?
 ...


I do end up using the changelogs to see what past releases are, so I can
downgrade (some times). Those changes are most useful for me -- not the
most recent always, but the ones that change release numbers.

Aria

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: SPECS: hula.spec (NEW) - added, NFY (from fedora extras)

[Aredridel]

On Tue, 2006-03-14 at 08:19 +0100, Andrzej Krzysztofowicz wrote:
 aredridel wrote:
  +Source1:   %{name}.init
 [...]
  +install -D %{SOURCE1} -D $RPM_BUILD_ROOT/%{_sysconfdir}/rc.d/init.d/hula
 
 Using a HTML file here does not seem to be a good idea...

Oh, oops. Working too fast and hadn't gotten as far as testing the
initscript. I'm rested now, back at it after work.

Aria

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: apache conflicts - strange rpm behaviour

[Aredridel]

On Fri, 2006-01-13 at 20:35 +0100, Jakub Bogusz wrote:
 # rpm -q rpm apache apache-base
 rpm-4.4.4-0.2.athlon
 apache-2.2.0-10.athlon
 apache-base-2.2.0-10.athlon
 # LC_ALL=C rpm -V apache
 Unsatisfied dependencies for apache-base-2.2.0-10.athlon:
 Conflicts: apache  2.2.0
 
 WTF?
 Is it specific to rpm-4.4.4?
 


[EMAIL PROTECTED]:~/rpm/SPECS$ rpm -q rpm apache apache-base
rpm-4.4.2-26
apache-2.2.0-10
apache-base-2.2.0-10
[EMAIL PROTECTED]:~/rpm/SPECS$ rpm -V apache
[EMAIL PROTECTED]:~/rpm/SPECS$

Seems so.

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: ANN: Closing AC

[Aredridel]

On Sun, 2005-12-11 at 19:18 +0100, Andrzej Krzysztofowicz wrote:
 =?UTF-8?B?TWFyY2luIEtyw7Ns?= wrote:
   I can't see what's  
   bothering ppl bout dying ac and th. Windows 98 and 95 and ME died as 
   well,  
   other distros also make new versions and move on forward.
  
  For me personally if we will switch to awlays in developement distro 
  it would be easier to:
  
  1) Maintain my machines, by simply doing poldek --upgrade-dist out of 
  stable tree. Occasionally there will be need to do some manual upgrades 
  like from postgres 8.0 to 8.1 which requires database dump/restore. Now 
 
 But if you leave one machine not upgraded, after some time it may become
 not upgradeable. Because of missing triggers, package splits, missing
 obsoletes, etc.

Perhaps it is time to start tracking those, and recording an upgrade
path.

  lets assume that we will stay with current distro politics + we will 
  release new version every year. So once a year I'll probably have to 
  reinstall all the machines because version Z was released and X has 
  reached an EOL.
 
 What for machines that are not upgradeable N - N+1? Eg. because of their
 configuration and bugs present in year N+1 release. Will rel. N+2 support
 N - N+2 upgrade ?
 Eg. some X11 version (or any other commonly used library) is unusable for
 them, suggested solution is to use previous version with bugfixes?

I think part of the problem is that we would need to keep old package
sets on FTP: A sort of mini-release with every batch of moves from ready
to main. If the distro tree is laid out for that, I can see it working
very well. Poldek 0.20's config files leave good infrastructure for
rolling out new repo locations via updates, too.

  2) Maintain distro itself. Now if there is some security bug it should 
  be fixed in Ra, Ac, Th. With always in developement we'll 
  prepare/commit/test/build fixed packages only once.
 
 Yes, leaving the work for machine admins is simpler.

Hehe.

Aria

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: ANN: Closing AC

[Aredridel]

On Sun, 2005-12-11 at 15:05 +0100, Jakub Bogusz wrote:
 On Sun, Dec 11, 2005 at 02:45:22PM +0100, Marcin Król wrote:
   It's ok as long, as we make ISO-s from time to time.
  
  That is the part of always in developement idea.
  
   I can't see what's  
   bothering ppl bout dying ac and th. Windows 98 and 95 and ME died as 
   well,  
   other distros also make new versions and move on forward.
  
  For me personally if we will switch to awlays in developement distro 
  it would be easier to:
  
  1) Maintain my machines, by simply doing poldek --upgrade-dist out of 
  stable tree. Occasionally there will be need to do some manual upgrades 
  like from postgres 8.0 to 8.1 which requires database dump/restore. Now 
  lets assume that we will stay with current distro politics + we will 
  release new version every year. So once a year I'll probably have to 
  reinstall all the machines because version Z was released and X has 
  reached an EOL.
 
 But think about big transitions, such as gcc - when most of
 C++/Fortran/Ada/GCJ-based Java stuff must be rebuilt. And many programs
 appear broken, so they wouldn't exist in distro even for few months.
 gcc 4.0 isn't so new now (about 8 months from 4.0.0 release has passed),
 but many programs still need fixes, sometimes non-trivial.

How possible are parallel installs? Could one not have both installed,
if packaged properly, and migrate as packages become fixed, eventually
having a system without GCC 3?

Perhaps it would be smart to define package sets:

AC + Gnome 2.12 + GCC 3
upgrade to AC + Gnome 2.14 + GCC 3 
install to AC + Gnome 2.14 + GCC 3 + GCC 4 
clean to AC + Gnome 2.14 + GCC 4

Each move like a mini distro upgrade, but without the long pain and
massive changes, each isolated into the package set. Like always in
development, but with tested groups of releases, not continuous updates.

Some continuous updates could happen within the framework, if each
module is a poldek repo with an updates repo attached, too.

Find sets of packages that mutually require upgrade -- like dist-upgrade
finds when installing -- and label them as distro addons (I don't like
the word) -- and you can upgrade entire subsets, without needing to
upgrade a whole distro.

Building this would require a few more tools, to check interdependencies
between repos. I don't think they would be hard to build. I think the
net win could be very big: stability, upgrade paths, rapid development,
short release cycle.

I have a friend who would like to not bother with many updates until a
new GNOME, then travel to where they have broadband and update. If he
could just enable a new repo and dist-upgrade, he'd be set very quickly.
Conceptually simple, manageable. For updates at home on dial-up
internet, he could just keep (security?)update repos for the groups of
packages enabled, and only do actual major updates when he has
broadband.

Aria

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: ANN: Closing AC

[Aredridel]

On Sun, 2005-12-11 at 16:07 +0100, Jakub Bogusz wrote:
 On Sun, Dec 11, 2005 at 03:54:20PM +0100, [EMAIL PROTECTED] wrote:
  Dnia Sun, 11 Dec 2005 14:52:49 +0100, Adam Gołębiowski  
  [EMAIL PROTECTED] napisał:
  
   On Sun, Dec 11, 2005 at 02:45:22PM +0100, Marcin Król wrote:
   1) Maintain my machines, by simply doing poldek --upgrade-dist out of
   stable tree. Occasionally there will be need to do some manual upgrades
   like from postgres 8.0 to 8.1 which requires database dump/restore. Now
   lets assume that we will stay with current distro politics + we will
   release new version every year. So once a year I'll probably have to
   reinstall all the machines because version Z was released and X has
   reached an EOL.
  
  All of that is true - as long as from time to time we'll bake some iso,  
  everything is fine for me.
  
   What about some groundbraking change like gcc update (breaking BC)?
  
  That'd be a point to make an iso - perfect for making some 'version',  
  'release', 'snapshot' or whatever You call it - an iso.
 
 And what can I do with ISO full of security holes (or other serious
 bugs), with only binary-incompatible updates on ftp?
 
 always in development works good only for periods of time limited by
 big transitions.

Maybe medium transitions with less time between could be possible? C++
ABI breakage is the biggest I can think of. Otherwise, major transitions
are relatively small.

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en