Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 7 FirstFirst 12345 ... LastLast
Results 21 to 30 of 66
  1. #21
    Senior Member JackOfAll's Avatar
    Join Date
    Dec 2005
    Location
    London, UK
    Posts
    2,749
    Quote Originally Posted by mherger View Post
    I don't know where all the Raspberries, Wandboards etc. would be to be
    found. JackOfAll - would CSOS report as Redhat or generic Linux?
    Need to come back to you on that. (I'm "on the road" at the moment.) Best guess right now, generic Linux. That'll include the CS releases, the still un-anounced but available SC, which now has 100 or so users, the VortexBox guys wanting the latest 7.9 on top of VortexBox, some F20 ARM users, F20 desktop users, a couple of guys testing my most recent packaging, bringing LMS for Pidora (Pi armv6) into the fold.....

    I will have very limited time this week. If the chap packaging for Gentoo (sorry I forget you name) could PM me.... If anyone interested in packaging for Debian could also PM me.... I will be able to provide a build farm, as many KVM's with different versions of Debian installed for you to build and package from source. (Not sure how the upstream packaging for deb is working, definitely not my area of expertise, but I suspect..... In as much as the deb/rpm packages aren't being produced directly from source, but from a pre-built binary tar ball. That needs to change.....)
    Last edited by JackOfAll; 2014-09-09 at 04:17.

  2. #22
    Senior Member hickinbottoms's Avatar
    Join Date
    Apr 2005
    Location
    Wokingham, UK
    Posts
    544
    Quote Originally Posted by JackOfAll View Post
    If the chap packaging for Gentoo (sorry I forget you name) could PM me....
    Have PM'd. I summarised my view of options for the record that I also included in the PM but may be of wider interest:

    I've found LMS to be very fussy over the versions of the CPAN packages it depends on, so we'd have to either:

    1. Fix the dependencies to the exact packages that LMS already works with, but that would cause problems with preventing CPAN module updates being allowed to be installed, conflicting dependencies between LMS and some other packages which couldn't be simultaneously satisfied, and wouldn't incorporate the patches that Logitech have been carrying to those packages.

    2. Find and eradicate dependencies to CPAN packages and move more to 'native' built-in capabilities. I'm sure that can be done in some cases, but there'll definitely be many packages that add significant capability that would be difficult to replace with volunteer effort (templating, database, media metadata etc) so the problem wouldn't entirely go away.

    3. Swallow having to distribute binaries of CPAN modules and the Perl bits for 'private' installation within the LMS tree, then think about how to best distribute those (as was the subject of the original discussion).

    Personally I'm not at all against 1 or 2, but wouldn't have any time to really contribute much.

    Option 3 has the advantage of being 'proven' if inconvenient for Logitech. I think 1 and 2, even if we could do it, would need continuous work as distributions up their packaged versions of CPAN modules so users would find things break without having changed their LMS install at all.

    I understand the distaste with option 3, but we would need a practical alternative that I'm finding hard to imagine at the moment. I'm fully prepared for a revelation and learn something that changes that opinion, though!

    Stuart
    "Never put off until tomorrow what you can put off until the day after - with Lazy Searching!"

  3. #23
    Senior Member JackOfAll's Avatar
    Join Date
    Dec 2005
    Location
    London, UK
    Posts
    2,749
    Quote Originally Posted by hickinbottoms View Post
    Have PM'd. I summarised my view of options for the record that I also included in the PM but may be of wider interest:
    Stuart, received. Reply later.

    Quote Originally Posted by hickinbottoms View Post
    3. Swallow having to distribute binaries of CPAN modules and the Perl bits for 'private' installation within the LMS tree, then think about how to best distribute those (as was the subject of the original discussion).
    I cant remember who it was, I was having the discussion with..... Might have been you, might have been the chap using my rpm spec files for CentOS builds......

    Was it you who had a list of which CPAN modules dependencies for LMS, could be fulfilled by "upstream" distribution supplied packages, and which couldn't, either because of the need for a specific (old) version, or changes that never made it back to upstream? Might not have been you, could have been the CentOS guy. For my builds, I went for the obvious cases, not shipping "private" modules where the LMS private module was the same version as "upstream" and continuing to package "private" modules where there were obvious changes, version specific dependency, or some such.

    Stuart, Gentoo is a corner case, (compared to some), in as much as it is a source based distribution rather than shipping binaries. But I assume like all other distributions, if you had a dedicated community "repo" hosted somewhere, people could "emerge" from that repo, (or whatever thay need to do, sorry, not familiar with the Gentoo terminology), after installing whatever they needed to install (repo config) to point at that repo?

    Leaving the NAS builds to one side for the moment, the community should IMHO take over the provision of builds for the various Linux distributions that we want to see supported. That's our starting point. Providing the hosting, providing the resources, (build environments), is no problem. Getting the various people involved to take responsibility for these community builds, and put the time in, that's a bit harder.

    Michael is in an impossible position with what he is already trying to suport, the number of perl versions, the different arches, the different distributions..... Erland is right when he says that Michael needs to spend his time working on LMS, not packaging it.

    We, as the community, need to take care of packaging for the "stock" Linux platforms we use and want to see supported..... As a starting point, I'd like to see community packaging taking place for RPM (Fedora/CentOS/SuSe), DEB (Debian/Ubuntu), and Gentoo. I can help out with supporting more than "stock" Fedora and VortexBox from my RPM builds. You have Gentoo covered, if you can find the time. It's a couple of Ubuntu/Debian guys that we need to get involved.

  4. #24
    Quote Originally Posted by mherger View Post
    SSODS 4.x (Synology DiskStation) 0.02%
    I'd run LMS on Synology, but last I checked the package provided runs LMS as root, so it was a no go in my book.

  5. #25
    Senior Member hickinbottoms's Avatar
    Join Date
    Apr 2005
    Location
    Wokingham, UK
    Posts
    544
    Quote Originally Posted by JackOfAll View Post
    Was it you who had a list of which CPAN modules dependencies for LMS, could be fulfilled by "upstream" distribution supplied packages, and which couldn't, either because of the need for a specific (old) version, or changes that never made it back to upstream?
    Although I had to consider similar things to this, it wasn't me you were talking to about this.

    Quote Originally Posted by JackOfAll View Post
    Stuart, Gentoo is a corner case, (compared to some), in as much as it is a source based distribution rather than shipping binaries. But I assume like all other distributions, if you had a dedicated community "repo" hosted somewhere, people could "emerge" from that repo, (or whatever thay need to do, sorry, not familiar with the Gentoo terminology), after installing whatever they needed to install (repo config) to point at that repo?
    Yep -- if the package is pointing at source or binaries hosted somewhere else then that's fine. The 'packages' for Gentoo essentially consist of build scripts that download and build things from source together with dependencies on other packages -- what those packages build is generally downloaded from the upstream projects' directly by those Gentoo package scripts rather than being re-hosted in the Gentoo repositories.
    "Never put off until tomorrow what you can put off until the day after - with Lazy Searching!"

  6. #26
    Member Candlemass's Avatar
    Join Date
    Aug 2014
    Location
    Germany
    Posts
    91
    Quote Originally Posted by jvromans@squirrel.nl View Post
    Michael Herger <slim (AT) herger (DOT) net> writes:

    >> Having 'enjoyed' packing on Gentoo over the years I originally tried to
    >> split out the dependencies and rely on distribution-provided Perl
    >> modules, which nealy finished me off due to there being so many of them.

    >
    > Everybody suggesting "use the distro's libraries" please read above
    > paragraph carefully. Thanks Stuart for describing the situation :-).


    Still, IMNSHO, "use the distro's libraries" is the right way to go.
    At least, for platforms that have decent package management (eg.,
    Debian, RedHat, Suse, Fedora, Ubuntu, ...).

    The LMS dependency tree is insane. To simplify this means simplifying
    LMS' use of arbitrary CPAN modules. LMS was clearly developed in a time
    when the "for every problem there's a solution on CPAN" adagium was
    leading. Although that may be quite true, the end result is,
    unfortunately, a mess.

    For all my serious software packages (especially the ones that get
    distributed to many mostly unknowing users) I have taken the approach to
    avoid CPAN modules as much as possible, except for well-known
    well-established modules of outstanding quality and proven stability.

    This means analyzing why each module is used. Often only a very limited
    number of functions from a particular module are actually used; in this
    case these functions could be added to a LMS module. Sometimes
    diffferent modules are used for more or less the same purpose; it may be
    worth trying to rewrite the calling code to use only one of the modules.
    Modules that are known to break LMS (eg., newer versions of DBIx::Class)
    can be copied into the LMS source tree. Modules that are okay on
    themselves but require an insane number of dependencies irrelevant to
    LMS can be copied to the LMS source tree and have most dependencies
    removed.

    Although this will only marginally improve the code quality of LMS, it
    will significantly improve building and maintainability.

    Just my Ô‚Č0.02.

    -- Johan
    That's IMHO the way to go on the programmers side. First try to reduce the dependency list, then remove all the dependency stuff from the LMS package. The LMS source tree with all the perl stuff at the moment is huge and confusing, which drives every packager mad.
    Also remove the whole decoder/encoder stuff from the binary packages. This has to be resolved by the distribution. Also you cannot provide all the necessary versions anyway (ARM hard float, soft float, oabi).

    Provide a simple list of all needed dependencies with the name of the source archives, maybe the recommended version and the website link. Makes live a lot easier for packagers and users.

  7. #27
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,366

    How to deal with LMS' Perl binaries mess onLinux?...

    > That's IMHO the way to go on the programmers side. First try to reduce
    > the dependency list, then remove all the dependency stuff from the LMS
    > package. The LMS source tree with all the perl stuff at the moment is
    > huge and confusing, which drives every packager mad.


    Don't you think it's a bit simplistic when you think the developer shall
    deal with all the compatibility issues different versions of those
    modules are causing, just to simplify the packager's life?

    Feel free to go ahead and start sorting out the requirements which can
    be resolved by default modules. Make sure removing them doesn't break
    functionality with Perl 5.8-5.20 (Linux), 5.10-5.18 (OSX) and 5.14
    (Windows).

    > Also remove the whole decoder/encoder stuff from the binary packages.
    > This has to be resolved by the distribution. Also you cannot provide all
    > the necessary versions anyway (ARM hard float, soft float, oabi).


    The packager who is willing to resolve those dependencies can easily
    just ignore those pre-built versions. Just make sure your user knows why
    things fail when using your package :-).

    Unfortunately this discussion didn't quite go the way I hoped it would
    (but the way I feared it would). I said from the beginning that I knew
    the perfect world approach, and that I knew it wasn't going to happen,
    lack of resources.

    I'll say it again: we need action, not words. Otherwise I'm going to do
    whatever helps me improve the situation the way _I_ can handle it. Or
    I'll leave myself some time and just leave it the way it is now.

    Many thanks go to those who try to resolve this issue for one platform
    or an other by providing optimized packages for them. I appreciate it.
    And I'll do my best to support you.

    --

    Michael

  8. #28
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,366

    How to deal with LMS' Perl binaries mess onLinux?...

    > Michael, please don't make any knee-jerk decisions.

    Hmm... is doing nothing a knee-jerk reaction? :-)

    > Even though it may
    > seem counter productive, just build those CPAN modules for that new
    > Debian release for the moment and bundle them for the moment.


    I guess that's what's going to happen. Just a few more MB to the already
    bloated archives.

    > And Michael, if you have any spare time, please work on reducing the
    > number of "private" CPAN packages.


    There indeed is some slack to cut. Eg. modules we no longer use, or
    where we only use a couple of lines from a larger package (eg.
    Cache::Cache). Or one file we only patched to work around a Windows
    limitation.

    But then I know that there will be 3rd party plugins relying on them.
    How to deal with Windows users? While you can tell a desktop Linux user
    to "yum install perl-yadda", the Windows user doesn't even have Perl.
    What about the NAS user, who bought a NAS because he didn't want to deal
    with Linux? The plugin developer would have to provide all those
    dependencies...

    > Trying to get code upstreamed where
    > you have made changes to CPAN packages. Trying to reduce the number of
    > LMS specific (requiring a specific version or changes to) dependencies,
    > so we can use upstream system packages whereever possible. That's the
    > way to go about making LMS easier to package/maintain.


    The other day I was tempted to remove the version check and our CPAN
    folder, just to see how far I got. But I need some more time. Did anyone
    ever do this? Eg. try to remove all modules we didn't patch and replace
    them with whatever your perl version would provide?

    --

    Michael

  9. #29
    jvromans@squirrel.nl
    Guest

    How to deal with LMS' Perl binaries mess onLinux?...

    Michael Herger <slim (AT) herger (DOT) net> writes:

    > Don't you think it's a bit simplistic when you think the developer
    > shall deal with all the compatibility issues different versions of
    > those modules are causing, just to simplify the packager's life?


    No, but with a little bit of cooperation the lifes of both can be made a
    lot more pleasant.

    -- Johan

  10. #30
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,366

    How to deal with LMS' Perl binaries mess onLinux?...

    >> Don't you think it's a bit simplistic when you think the developer
    >> shall deal with all the compatibility issues different versions of
    >> those modules are causing, just to simplify the packager's life?

    >
    > No, but with a little bit of cooperation the lifes of both can be made a
    > lot more pleasant.


    Co-operation is a very nice term. It means working together, doesn't it? :-)

    --

    Michael

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •