Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
LaTeX
10-27-2014, 04:26 PM
Post: #11
RE: LaTeX
(10-27-2014 02:02 AM)tavvva Wrote:  icu is the only package out of 458 that suffers from this issue ... it's really a bad luck you chose this one

the solution is simple ... join the build() and package() functions

I'm happy to confirm that this works and icu compiles, so after bumping the release version this could co to the binary repos.

I simply chose it, because TeXLive depends on it. It is one step further to make Deli(cate) really useful.
Find all posts by this user
Quote this message in a reply
10-27-2014, 04:37 PM
Post: #12
RE: LaTeX
(10-27-2014 04:26 PM)MSW Wrote:  
(10-27-2014 02:02 AM)tavvva Wrote:  icu is the only package out of 458 that suffers from this issue ... it's really a bad luck you chose this one

the solution is simple ... join the build() and package() functions

I'm happy to confirm that this works and icu compiles, so after bumping the release version this could co to the binary repos.

I simply chose it, because TeXLive depends on it. It is one step further to make Deli(cate) really useful.

The reason why I kept icu broken for so long lies in my inability to generate a lightweight version of the package in a reasonable time window. Maybe you noticed, that the icu stuff is pretty huge and therefore not very suitable for this distro. I know that icu can be stripped to a small subset of features, but that could go against your goal. Maybe we could introduce two concurrent versions of icu and the full featured could be put in a separate repository with heavy and bloated stuff. This kind of decisions is the most difficult on this work.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-12-2014, 01:19 AM
Post: #13
RE: LaTeX
(10-27-2014 04:37 PM)tavvva Wrote:  The reason why I kept icu broken for so long lies in my inability to generate a lightweight version of the package in a reasonable time window. Maybe you noticed, that the icu stuff is pretty huge and therefore not very suitable for this distro. I know that icu can be stripped to a small subset of features, but that could go against your goal. Maybe we could introduce two concurrent versions of icu and the full featured could be put in a separate repository with heavy and bloated stuff. This kind of decisions is the most difficult on this work.

Generating a lightweight version of icu might be a project on its own - and for compatibility reasons should be its own package I'd say.
Regarding the decisions I'd go with the bloated stuff. Most of the target machines should have at least 1-2 Gig of harddrives and 40-64 Megs of RAM.
Having a functional distro will attract people to use it and then in turn these people will contribute, because they have needs and want to stay with this distro.
For me, I arrived here by updating from Deli (because after starting from Linux I knew that this would support PCMCIA-Networking without hassle and so on)
Another big step would be moving from uCLibc to Musl, which seems actively maintained whereas uClibc hasn't seen updates for mote than 2 years. There seem to be a few distros favouring Musl [1]. But then again Starch Linux seems also dead. Eeerie [2] is far less usable than Deli while Sabotage [3] is LFS-based and not as accessible as an Arch-based distro (from a user perspective).

However, Delicate has its niche and should get all the love it needs.

[1] http://wiki.musl-libc.org/wiki/Projects_using_musl
[2] https://eerielinux.wordpress.com/about/
[3] https://github.com/sabotage-linux
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)

Contact Us | DeLi(cate) Linux | Return to Top | Return to Content | Lite (Archive) Mode | RSS Syndication