On 2017-01-26 23:12, René J.V. Bertin wrote: > On Thursday January 26 2017 21:56:59 Rainer Müller wrote: >> Looking at the VLC port it looks like the subport ffmpeg-VLC and >> the main port have nothing in common at all. > > You're not wrong but that's not entirely true either, the subport > builds an ffmpeg version that's patched specifically for use by VLC, > and VLC also has a few patches to make it work with that ffmpeg > build. They're only subports because it's not supposed to be a > permanent solution and as such it didn't feel right either to make > ffmpeg-VLC a standalone port.
It does not matter whether this is permanent or temporary. After installation, subports are just like any other port. If it will not be required in the future, it will be just like a dropped dependency that is no longer referenced from any other port. >> Don't force yourself to use subports if it adds unwanted >> complexity. > > That's true, but splitting off really related ports into separate > port directories also adds complexity which to me can be more > cumbersome to deal with in practice than the main kind of complexity > that (lots of) subports cause: a big file. Maybe in other cases. In the case of ffmpeg-VLC, I say it reduces complexity to use a separate port. > Let's take another example then: my KF5-Frameworks meta-port > (https://github.com/RJVB/macstrop/blob/master/kf5/KF5-Frameworks/Portfile), > which shares a number of properties with port:qt5's Portfile. It's > essentially a list of relatively simple subports, one each for the > 60+ KF5 Frameworks with a few -devel versions thrown in, plus some > common code and variants. The subports are simple because a lot of So, there are about 100 lines before lots of subports {} are defined. Why can't these be moved to a PortGroup, referenced from individual Portfiles with normal checksums? Maybe I am missing something from my quick look, but I do not see the advantage of using subports here. The only shared option is the version number? > because the > checksums are stored in a table that's defined in a file in > ${filespath}. This would already cause trouble as this file is not taken into account for the modification check (via Portfile checksum) in the statefile. Modifications to the checksum file alone would not lead to cleaning of a previously created work directory. This could be solved, though. The state file would need to record which other files were included and check them as well. > Still, it's a bit unwieldy at over 2300 lines, and as > such I'd love to be able to break it up following the Tier1,2,3,4 + > PortingAids categorisation that KDE use (where the tiers correspond > to the level of framework inter-dependencies). There are a meta-ports > corresponding to those tiers but there's no functional argument that > would justify making those standalone meta-ports. That organisation > only makes sense during upgrade cycles; these frameworks are > version-linked, and when upgrading you start with the Tier1 level and > end with the porting aids. The thing is whether you want to argue to make them subports or keep them separate. In my opinion, separate ports is the default case and subports are for special cases such as -devel ports or providing the same for multiple python/etc. versions, which is exactly for what subports were originally introduced. > So ideally I'd have a Portfile that includes the checksum table, and > then Portfile.{tier1,tier2,tier3,tier4,portingAids} . The checksum > table doesn't need to be copied into the registry, but the other 5 > files would. Actually, I don't know if it'd be the ideal solution > because I haven't tested it, but I'm quite certain I wouldn't want to > have to deal with the code duplication and keeping-in-sync that would > come from splitting up the beast. Code can be moved to a port group. That would only leave updating version and checksums. All other variables I see are already defined by a port group. But after all, you maintain this. This does not convince me that including other files into Portfiles has a large benefit, although adding more work in base. Rainer
